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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.401 Performance Management (PM); Concept and requirements 

52.402 Performance Management (PM); Performance measurements - GSM 

32.404 Performance Management (PM); Performance measurements - Definitions and template 

32.405 Performance Management (PM); Performance measurements Universal Terrestrial Radio Access 
Network (UTRAN) 

32.406 Performance Management (PM); Performance measurements Core Network (CN) Packet Switched 
(PS) domain 

32.407 Performance Management (PM); Performance measurements Core Network (CN) Circuit 
Switched (CS) domain 

32.408 Performance Management (PM); Performance measurements Teleservice 

32.409 Performance Management (PM); Performance measurements IP Multimedia Subsystem (IMS) 

32.425 Performance Management (PM); Evolved Performance measurements Universal Terrestrial 
Radio Access Network (E-UTRAN) 

32.426 Performance Management (PM); Evolved Packet Core (EPC) 



The present document is part of a set of specifications, which describe the requirements and information model 
necessary for the standardised Operation, Administration and Maintenance (OA&M) of a multi-vendor E-UTRAN and 
EPC system. 

During the lifetime of an E-UTRAN, its logical and physical configuration will undergo changes of varying degrees and 
frequencies in order to optimise the utilisation of the network resources. These changes will be executed through 
network configuration management activities and/or network engineering, see TS 32.600 [3]. 
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Many of the activities involved in the daily operation and future network planning of an E-UTRAN require data on 
which to base decisions. This data refers to the load carried by the network and the grade of service offered. In order to 
produce this data performance measurements are executed in the NEs, which comprise the network. The data can then 
be transferred to an external system, e.g. an Operations System (OS) in TMN terminology, for further evaluation. The 
purpose of the present document is to describe the mechanisms involved in the collection of the data and the definition 
of the data itself. 

Annex B of TS 32.404 helps in the definition of new performance measurements that can be submitted to 3GPP for 
potential adoption and inclusion in the present document. Annex B of TS 32.404 discusses a top-down performance 
measurement definition methodology that focuses on how the end-user of performance measurements can use the 
measurements. 
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1 Scope 

The present document describes the measurements for E-UTRAN. 

TS 32.401 [5] describes Performance Management concepts and requirements. 

The present document is vaHd for all measurement types provided by an implementation of an E-UTRAN. 

Only measurement types that are specific to E-UTRAN are defined within the present documents. Vendor specific 
measurement types used in E-UTRAN are not covered. Instead, these could be applied according to manufacturer's 
documentation. 

Measurements related to "external" technologies (such as ATM or IP) as described by "external" standards bodies (e.g. 
ITU-T or IETF) shall only be referenced within this specification, wherever there is a need identified for the existence 
of such a reference. 

The definition of the standard measurements is intended to result in comparability of measurement data produced in a 
multi-vendor network, for those measurement types that can be standardised across all vendors' implementations. 

The structure of the present document is as follows: 

Header 1: Network Element (e.g. measurements related to eNodeB); 

Header 2: Measurement function (e.g. RRC connection setup related measurements); 

Header 3: Measurements. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.600: "Telecommunication management; Configuration Management (CM); Concept 

and high-level requirements". 

[4] Void. 

[5] 3GPP TS 32.401: "Telecommunication management; Performance Management (PM); Concept 

and requirements". 

[6] 3GPP TS 32.404: "Performance Management (PM); Performance measurements - Definitions and 

template". 

[7] 3GPP TS 32.762: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Network 

Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS)". 

[8] 3GPP TS 36.33 1 : "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource 

Control (RRC) protocol specification". 
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[9] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); SI 

Application Protocol (SlAP)". 

[10] 3GPP TS 36.423: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 

application protocol (X2AP)". 

[11] 3GPP TS 36.314: "Evolved Universal Terrestrial Radio Access (E-UTRA); Layer 2 - 

Measurements". 

[12] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA); and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 

[13] 3GPP TS 32.450: "Telecommunication management; Key Performance Indicators (KPI) for E- 

UTRAN: Definitions". 

[14] 3GPP TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) 

procedures in idle mode". 

[15] 3GPP TS 32.522: "Technical Specification Group Services and SystemAspects; 

Telecommunication management; Self-Organizing Networks (SON) Policy Network Resource 
Model (NRM) Integration Reference Point (IRP); Information Service (IS)". 

[16] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access 

Control (MAC) protocol specification". 

[17] 3GPP TS 23.272, "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2". 

[18] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource 

Control (RRC); Protocol specification". 



Measurement family and abbreviations 



3.1 IVIeasurement family 



The measurement names defined in the present document are all beginning with a prefix containing the measurement 
family name (e.g. RRC.AttConnEstab.CoMie). This family name identifies all measurements which relate to a given 
functionality and it may be used for measurement administration (see TS 32.401 [5]). 

The list of families currently used in the present document is as follows: 

DRB (measurements related to Data Radio Bearer) 
RRC (measurements related to Radio Resource Control) 
RRU (measurements related to Radio Resource Utilization) 
ERAB (measurements related to E-RAB) 
HO (measurements related to Handover) 
SISIG (measurements related to SI Signalling) 
SRB (measurements related to Signalling Radio Bearer) 
PAG (measurements related to Paging) 
EQPT(measurements related to Equipment) 
UECNTX(measurements related to UE CONTEXT) 
TB (measurements related to Transport Block) 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



3G 


3"* Generation 


3GPP 


3G Partnership Project 


BLER 


Block Error Rate 


CRC 


Cyclic Redundancy Check 


EPS 


Evolved Packet System 
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EQPT 


Equipment 


E-UTRAN 


Evolved UTRAN 


E-RAB 


E-UTRAN Radio Access Bearer 


HO 


Handover 


QoS 


Quality of Service 


RN 


Relay Node 


TB 


Transport Block 


UTRAN 


Universal Terrestrial Radio Access Network 



You can find below a list of abbreviations used within the measurement types for field E of the measurement template 
(see 3GPP TS 32.404 [6]). 



Alloc 


Allocation 


Att 


Attempt(s,ed) 


Conn 


Connection 


Ded 


Dedicated 


DL 


Downlink 


ENB 


eNodeB 


Err 


Error 


Estab 


Establish (ed,ment) 


Fail 


Fail(ed, ure) 


Freq 


Frequency 


Inc 


Incoming 


Out 


Outgoing 


Pkt 


Packet(s) 


Prep 


Prepare(/Preparation) 


Late 


Latency 


Mod 


Modify(/Modification) 


Nbr 


Number 


Rel 


Release(s,d) 


Res 


Resource 


Succ 


Success(es,ful) 


Tot 


Total 


UL 


Uplink 



4 Measurements related to eNodeB, Donor eNodeB 

and Relay Node 

4.0 Applicability of measurements 

Without particular constraint, the measurements apply to following scenarios 

1) eNodeB serving one or more Relay Nodes. 

2) eNodeB not serving any Relay Node 

If the specific constraint is present, which one of above scenarios the subject measurement applies to, 
is following the constraint. 



4.1 



RRC connection related measurements 



4.1 .1 RRC connection establishment 

The three measurement types defined in the subclauses 4.1.1.1, 4.1.1.2 and 4.1.1.3 are subject to the "2 out of 3 
approach". 
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4.1 .1 .1 Attempted RRC connection establishments 

a) This measurement provides the number of RRC connection establishment attempts for each estabhshment cause. 

b) CC 

c) Receipt of an RRCConnectionRequest message by the eNodeB/RN from the UE. Each RRCConnectionRequest 
message received is added to the relevant per establishment cause measurement. The possible causes are 
included in TS 36.331 [8]. The sum of all supported per cause measurements shall equal the total number of 
RRCConnectionRequest. In case only a subset of per cause measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRC.ConnEstabAtt.CflM^e 
where Cause identifies the establishment cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.1 .1 .2 Successful RRC connection establishments 

a) This measurement provides the number of successful RRC establishments for each establishment cause. 

b) CC 

c) Receipt by the eNodeB/RN of an RRCConnectionSetupComplete message following a RRC connection 
establishment request. Each RRCConnectionSetupComplete message received is added to the relevant per 
establishment cause measurement. The possible causes are included in TS 36.331 [8]. The sum of all supported 
per cause measurements shall equal the total number of successful RRC Connection Establishments. In case only 
a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRCConnEstabSuccCflM^e 
where Cause identifies the establishment cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.1 .1 .3 Failed RRC connection establishments 

a) This measurement provides the number of RRC establishment failures for each establishment cause. 

b) CC 

c) Transmission of an RRCConnectionReject message by the eNodeB/RN to the UE or an expected 
RRCConnectionSetupComplete message not received by the eNodeB/RN. Each failed RRC connection 
establishment is added to the relevant per establishment cause measurement. The possible causes are included in 
TS 36.331 [8]. 

The sum of all supported per cause measurements shall equal the total number of RRC connection establishment 
failures. In case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 
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e) The measurement name has the form RRC.ConnEstabFail.CaM.se 
where Cause identifies the estabHshment cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.1 .1 .4 Failed RRC connection establishment per failure cause 

a) This measurement provides the number of failed RRC establishment per failure cause. This measurement is to 
support LBO target setting and evaluation, see [15] 

b) CC 

c) Transmission of an RRCConnectionReject message by the eNodeB to the UE. 

Each transmitted RRCConnectionReject message caused by 'congestion' is added to the measurement cause 
"Congestion" , when eNB receives an RRCConnectionRequest message and the RRC connection is not 
established because the eNB is going to Energy Saving mode is added to the measurement cause 
"EnergySaving" and each transmitted RRCConnectionReject message caused by the other reasons is added to 
measurement cause "Unspecified" . 

d) Each measurement is an integer value. 

e) RRC.ConnEstabFaileNBCause.Conge.sf/on 
RRC.ConnEstabFaileNBCause.f/nipeoyiefi 
RRC.ConnEstabFaileNBCause.Zinergy^flv/ng 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 

h) EPS 

i) The measurement is use to count "Failed RRC connection establishment related to load" for LBO target setting 
and evaluation, see [15]. 

4.1 .2 RRC connection re-establishment 

The three measurement types defined in the subclause 4.1.2.n are subject to the "2 out of 3 approach". 

4.1 .2.1 Attempted RRC connection re-establishments 

a) This measurement provides the number of RRC connection re-establishment attempts for each re-establishment 

cause. 

b) CC. 

c) Receipt of an RRCConnectionReestablishmentRequest message by the eNodeB/RN from the UE. Each 
RRCConnectionReestablishmentRequest received is added to the relevant per reestablishment cause 
measurement. The possible causes are included in TS 36.331 [8]. The sum of all supported per cause 
measurements shall equal the total number of RRC connection re-stablishment attempts. In case only a subset of 
per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRC.ConnReEstabAtt.CoMse 
where Cause identifies the reestabhshment cause. 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 



4.1.2.2 



Successful RRC connection re-establishments 



a) This measurement provides the number of successful RRC connection re-establishments for each re- 
establishment cause. 

b) CC. 

c) Receipt by the eNodeB/RN of an RRCConnectionReestablishmentComplete message following a RRC 
connection reestablishment request. Each RRCConnectionReestablishmentComplete message received is added 
to the relevant per reestablishment cause measurement. The possible causes are included in TS 36.331 [8]. The 
sum of all supported per cause measurements shall equal the total number of successful RRC connection re- 
establishments. In case only a subset of per cause measurements is supported, a sum subcounter will be provided 
first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRCConnReEstabSuccCawse 
where Cause identifies the establishment cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.1 .2.3 Failed RRC connection re-establishments 

a) This measurement provides the number of RRC re-establishment failures for each re-establishment cause. 

b) CC. 

c) Transmission of an RRCConnectionReestablishmentReject message by the eNodeB/RN to the UE or an 
expected RRCConnectionReestablishmentComplete message not received by the eNodeB/RN. 

Each failed RRC connection re-establishment is added to the relevant per re-establishment. cause measurement. 
The possible causes are included in TS 36.331 [8]. 

The sum of all supported per cause measurements shall equal the total number of RRC connection re- 
establishment failures. In case only a subset of per cause measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRC.ConnReEstabFail.CflMse 
where Cause identifies the re-establishment.cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 
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4.1 .3 RRC connection number 

4.1 .3.1 Mean number of RRC Connections 

a) This measurement provides the mean number of RRC Connections during each granularity period. 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval, the number of RRC connections for each E- 
UTRAN Cell and then taking the arithmetic mean 

d) A single integer value. 

e) RRC.ConnMean 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.1 .3.2 Maximum number of RRC Connections 

a) This measurement provides the maximum number of RRC Connections during each granularity period. 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval, the number of RRC connections for each E- 
UTRAN cell and then taking the maximum. 

d) A single integer value. 

e) RRC.ConnMax 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.1.4 RRC connection setup time 

4.1 .4.1 Mean RRC connection setup time 

a) This measurement provides the mean time per establishment cause it takes to establish an RRC connection. 

b) DER(n=l). 

c) This measurement is obtained by accumulating the time intervals for every successful RRC connection 
establishment between the receipt of a RRCConnectionRequest and the corresponding 

RRCConnectionSetupComplete message by the eNodeB/RN over the granularity period. The end value of this 
time will then be divided by the number of successful RRC connections observed in the granularity period to 
give the arithmetic mean. The accumulator shall be reinitialised at the beginning of each granularity period. The 
measurement is split into subcounters per establishment cause, and the possible causes are included in 

TS 36.331 [8]. 

d) Each measurement is an integer value (in milliseconds). 

e) The measurement name has the form RRC.ConnEstabTimeMean.CflMie 
where Cause identifies the establishment cause 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 



4.1 .4.2 Maximum RRC connection setup time 

a) This measurement provides the maximum time per estabHshment cause it takes to establish an RRC connection. 

b) GAUGE. 

c) This measurement is obtained by monitoring the time intervals for each successful RRC connection 
establishment between the receipt of a RRCConnectionRequest and the corresponding 

RRCConnectionSetupComplete message by the eNodeB/RN over the granularity period. The high tide mark of 
this time will be stored in a gauge, the gauge shall be reinitialised at the beginning of each granularity period. 
The measurement is split into subcounters per establishment cause, and the possible causes are included in 

TS 36.331 [8]. 

d) Each measurement is an integer value (in milliseconds). 

e) The measurement name has the form RRC.ConnEstabTimeMax.Cawse 
where Cause identifies the establishment cause 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 



4.1 .5 UE CONTEXT Release 

4.1 .5.1 Number of UE CONTEXT Release Request Initiated by eNodeB/RN 

a) This measurement provides the number of UE CONTEXT Release initiated by eNB/RN for each release cause. 

b) CC. 

c) Transmission of an UE CONTEXT RELEASE REQUEST message initiated by eNodeB/RN. Each release 
request is to be added to the relevant cause measurement. The possible causes are defined in 36.413 [9]. The sum 
of all supported per causes measurements shall equal the total number of UE CONTEXT Release initiated by 
eNodeB/RN. In case only a subset of per cause measurements is supported, a sum subcounter will be provided 
first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form UECNTX.RelReq. CflM^e 
where Cause identifies the release cause. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 
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i) By differenciate the causes, this measurement is used to count 'The number of abnormal RRC connection release 
related to load', which can be used for LBO target calculation.. 



4.1 .5.2 Successful UE CONTEXT Release 

a) This measurement provides the number of successful UE Context Release. 

b) CC. 

c) Sending of UE CONTEXT RELEASE COMPLETE from eNB/RN to MME/DeNB 

d) A single integer value. 

e) UEContext.RelSuccNbr. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching. 

h) EPS 

i) This measurement can be used to count 'the total number of RRC connection release', which can be used for 
LBO target calculation. 

4.2 E-RAB related measurements 

4.2.1 E-RAB setup 

4.2.1 .1 Number of initial E-RABs attempted to setup 

a) This measurement provides the number of initial E-RABs attempted to setup. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On receipt by the eNodeB/RN of an INITIAL CONTEXT SETUP REQUEST message, each requested E-RAB 
in the message is added to the relevant measurement per QCI, the possible QCIs are included in TS 36.413 [9]. 
The sum of all supported per QCI measurements shall equal the total number of E-RABs attempted to setup. In 
case only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstabInitAttNbr.gC/ 
where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.1 .2 Number of initial E-RABs successfully established 

a) This measurement provides the number of initial E-RABs successfully established. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) CC 
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c) On transmission by the eNodeB/RN of an INITIAL CONTEXT SETUP RESPONSE message, each E-RAB 
successfully established is added to the relevant measurement per QCI, the possible QCIs are included in 
TS 36.413 [9]. The sum of all supported per QCI measurements shall equal the total number of E-RABs 
successfully setup. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstablnitSuccNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.1 .3 Number of initial E-RABs failed to setup 

a) This measurement provides the number of initial E-RABs failed to setup. The measurement is split into 
subcounters per failure cause. 

b) CC 

c) On transmission by the eNodeB/RN of an INITIAL CONTEXT SETUP RESPONSE, or INITIAL CONTEXT 
SETUP FAILURE message, each E-RAB failed to establish is added to the relevant measurement per cause, the 
possible causes are included in TS 36.413 [9]. The sum of all supported per cause measurements shall equal the 
total number of E-RABs failed to setup. In case only a subset of per cause measurements is supported, a sum 
subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstablnitFailNbr. CflM^e 
where Cause identifies the cause resulting in the initial E-RAB setup failure. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.1 .4 Number of additional E-RABs attempted to setup 

a) This measurement provides the number of additional E-RABs attempted to setup. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On receipt by the eNodeB/RN of an E-RAB SETUP REQUEST message, each requested E-RAB in the message 
is added to the relevant measurement per QCI, the possible QCIs are included in TS 36.413 [9]. The sum of all 
supported per QCI measurements shall equal the total number of additional E-RABs attempted to setup. In case 
only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB. EstabAddAttNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 
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g) Valid for packet switched traffic 

h) EPS 

i) This measurement is to support the Accessibility KPI 'E-RAB Accessibility' defined in [13]. 

4.2.1 .5 Number of additional E-RABs successfully established 

a) This measurement provides the number of additional E-RABs successfully established. The measurement is split 
into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB SETUP RESPONSE message, each E-RAB successfully 
established is added to the relevant measurement per QCI, the possible QCIs are included in TS 36.413 [9]. The 
sum of all supported per QCI measurements shall equal the total number of additional E-RABs successfully 
setup. In case only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstabAddSuccNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Accessibility KPI 'E-RAB Accessibility' defined [13]. 

4.2.1 .6 Number of additional E-RABs failed to setup 

a) This measurement provides the number of additional E-RABs failed to setup. The measurement is split into 
subcounters per failure cause. 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB SETUP RESPONSE message, each E-RAB failed to establish 
is added to the relevant measurement per cause, the possible causes are included in TS 36.413 [9]. The sum of all 
supported per cause measurements shall equal the total number of additional E-RABs failed to setup. In case 
only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB. EstabAddFailNbr.CflM.se 

where Cause identifies the cause resulting in the additional E-RAB setup failure. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.1 .7 Mean E-RAB Setup time 

a) This measurement provides the mean time per QCI it takes to establish an E-RAB. 

b) DER(n=l) 
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c) This measurement is obtained by accumulating the time intervals for every successfully established E-RAB 
between the receipt of an E-RAB SETUP REQUEST or INITIAL CONTEXT SETUP REQUEST message and 
the transmission of the corresponding E-RAB SETUP RESPONSE or INITIAL CONTEXT SETUP 
RESPONSE message by the eNodeB over the granularity period. The end value of this time will then be 
divided by the number of successfully established E-RAB s in the granularity period to give the arithmetic mean. 
The accumulator shall be reinitialised at the beginning of each granularity period. The measurement is split into 
subcounters per QCI, and the possible QCIs are included in TS 36.413 [9]. 

d) Each measurement is an integer value (in milliseconds). 

e) The measurement name has the form ERAB.EstabTimeMean.QC/ 
where gC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.2.1 .8 Maximum E-RAB Setup time 

a) This measurement provides the maximum time per QCI it takes to establish an E-RAB. 

b) GAUGE 

c) This measurement is obtained by monitoring the time intervals for every successfully established E-RAB 
between the receipt of an E-RAB SETUP REQUEST or INITIAL CONTEXT SETUP REQUEST message and 
the transmission of the corresponding E-RAB SETUP RESPONSE or INITIAL CONTEXT SETUP 
RESPONSE message by the eNodeB over the granularity period. The high tide mark of this time will be stored 
in a gauge, the gauge shall be reinitialised at the beginning of each granularity period.. 

The measurement is split into subcounters per QCI, and the possible QCIs are included in TS 36.413 [9]. 

d) Each measurement is an integer value (in milliseconds). 

e) The measurement name has the form ERAB.EstabTimeMax.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.2.1 .9 Number of E-RABs attempted to establish for incoming HOs 

a) This measurement provides the number of E-RABs attempted to establish for incoming HOs. The measurement 
is split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On receipt by the eNB of a X2AP HANDOVER REQUEST or S 1 AP HANDOVER REQUEST message; or on 
transmission by the eNB of the RRCConnectionReconfiguration message to the UE triggering the intra-eNB 
handover (see TS 36.331 [8]), all E-RABs of this UE (but not only the E-RABs in the message) are counted for 
this measurement to the target E-UTRAN cell. Each E-RAB attempted to establish is added to the relevant 
measurement per QCI, the possible QCIs are included in TS 36.413 [9]. The sum of all supported per QCI 
measurements shall equal the total number of E-RABs attempted to setup. In case only a subset of per QCI 
measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstablncHoAttNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.1 .10 Number of E-RABs successfully established for incoming HOs 

a) This measurement provides the number of E-RABs successfully established for incoming HOs. The 
measurement is split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On transmission by the eNB of a X2AP HANDOVER REQUEST ACKNOWLEDGE or S 1 AP HANDOVER 
REQUEST ACKNOWLEDGE message, or on transmission by the eNB of the RRCConnectionReconfiguration 
message to the UE triggering the intra-eNB handover (see TS 36.331 [8]) after the E-RABs in this message are 
successfully established in the target E-UTRAN cell. Each E-RAB successfully established is added to the 
relevant measurement per QCI, the possible QCIs are included in TS 36.413 [9]. The sum of all supported per 
QCI measurements shall equal the total number of E-RABs successfully setup. In case only a subset of per QCI 
measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.EstablncHoSuccNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 



4.2.2 E-RAB release 

4.2.2.1 Number of E-RABs requested to release initiated by eNodeB/RN per QCI 

a) This measurement provides the number of E-RABs requested to release initiated by eNodeB/RN. The 
measurement is split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB RELEASE INDICATION, or an UE CONTEXT RELEASE 
REQUEST, or a RESET message to MME or DeNB( in case of RN), each corresponding E-RAB requested to 
release is added to the relevant measurement per QCI, the possible QCIs are included in TS 36.413 [9]. The sum 
of all supported per QCI measurements shall equal the total number of E-RABs requested to release initiated by 
eNodeB/RN. In case only a subset of per QCI measurements is supported, a sum subcounter will be provided 
first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.RelEnbNbr.QC/ 
where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
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h) EPS 

4.2.2.2 Number of E-RABs requested to release initiated by eNodeB/RN per cause 

a) This measurement provides the number of E-RABs requested to release initiated by eNodeB/RN. The 
measurement is spUt into subcounters per cause. 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB RELEASE INDICATION, or an UE CONTEXT RELEASE 
REQUEST, or a RESET message to MME or DeNB( in case of RN), each corresponding E-RAB requested to 
release is added to the relevant measurement per cause. Possible causes are included in TS 36.413 [9]. 

d) Each measurement is an integer value. The number of measurements is equal to the number of supported causes. 

e) The measurement names have the form ERAB.RelEnbNbr.cflM.se 

where cause identifies the reason for the E-RABs release request initiated by eNodeB/RN. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.2.3 Number of E-RABs attempted to release 

a) This measurement provides the number of E-RABs attempted to release. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On receipt by the eNodeB/RN of an E-RAB RELEASE COMMAND or UE CONTEXT RELEASE 
COMMAND or RESET message from MME/DeNB; or receipt by the eNodeB/RN of an UE CONTEXT 
RELEASE message from another eNodeB/DeNB or transmission by the eNodeB/RN of a an E-RAB Release 
Indication or RESET message to MME/DeNB; or on receipt by the eNB/RN of a PATH SWITCH REQUEST 
ACKNOWLEDGE or PATH SWITCH REQUEST FAILED message by which some or all E-RABs in the 
corresponding PATH SWITCH REQUEST need to be released; or on receipt by the eNB/RN of a 
RRCConnectionReconfigurationComplete message from the UE, indicating a successful intra-eNB/RN handover 
(see TS 36.331 [8]), i.e., the E-RABs in the cooresponding RRCConnectionReconfiguration message can be be 
released by the source EUtran cell. Each corresponding E-RAB to release is added to the relevant measurement 
per QCI, the possible QCIs are included in TS 36.413 [9]. , the same E-RAB shall not be counted repeatly but 
only one in case it appears more than one time in the same or different messages triggering this measurement 
The sum of all supported per QCI measurements shall equal the total number of E-RABs attempted to release. In 
case only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.RelAttNbr.^C/ 
where gC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.2.4 Number of E-RAB successfully released 

a) This measurement provides the number of E-RABs successfully released. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 
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b) CC 

c) On transmission by the eNodeB/RN of an E-RAB RELEASE RESPONSE or UE CONTEXT RELEASE 
COMPLETE, or E-RAB Release Indication or a RESET ACKNOWLEDGE to MME/DeNB; or E-RAB is 
released successfully by the eNB/RN after receiving PATH SWITCH REQUEST ACKNOWLEDGE or PATH 
SWITCH REQUEST FAILED messageby which some or all E-RABs in the corresponding PATH SWITCH 
REQUEST are to be released; or the E-RAB is released successfully at the source EUtran cell by the eNB/RN 
after receiving RRCConnectionReconfigurationComplete message from the UE, indicating a successful intra- 
eNB/RN handover (see TS 36.331 [8]); or the E-RAB released successfully by source eNB/RN after receiving 
UE CONTEXT RELEASE from another eNB/DeNB; or on receipt by the eNB/RN of a RESET 
ACKNOWLEDGE message from MME/DeNB . E ach corresponding E-RAB successfully released is added to 
the relevant measurenment per QCI, the possible QCIs are included in TS 36.413 [9] , the same E-RAB shall not 
be counted repeatly but only one in case it appears more than one time in the same or different messages 
triggering this measurement. The sum of all supported per QCI measurements shall equal the total number of E- 
RABs fully released. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.RelSuccNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 



4.2.2.5 Number of E-RAB failed to release 

a) This measurement provides the number of E-RAB failed to release. The measurement is split into subcounters 
per failure cause. 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB RELEASE RESPONSE message, each E-RAB failed to 
release is added to the relevant measurement per cause, the possible causes are included in TS 36.413 [9]. The 
sum of all supported per cause measurements shall equal the total number of E-RABs failed to release. In case 
only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.RelFailNbr.CflMse 
where Cause identifies the cause resulting in the E-RAB release failure. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.2.6 Number of released active E-RABs 

a) This measurement provides the number of released E-RABs that were active at the time of release. E-RABs 
with bursty flow are seen as being active when there is user data in the queue in any of the directions. E-RABs 
with continuous flow are always seen as active E-RABs in the context of this measurement. 
The measurement is split into subcounters per E-RAB QoS level (QCI). 
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b) CC 

c) On transmission by the eNodeB/RN of an E-RAB RELEASE INDICATION message; or on transmission by the 
eNB/RN of an E-RAB RELEASE RESPONSE message for the E-RAB release initiated by the MME/DeNB 
with the exception of corresponding E-RAB RELEASE COMMAND message with 'Cause' equal to 'Normal 
Release' or on transmission by the eNodeB/RN of UE CONTEXT RELEASE COMPLETE for the UE context 
release initiated by the eNB/RN with the exception of the corresponding UE CONTEXT RELEASE 
REQUEST message with cause 'User inactivity', 'CSG Subscription Expiry', or any 'cause' indicating a 
successful CS fallback (e.g., cause 'CS Fallback triggered', 'UE Not Available for PS Service', or 'Redirection 
towards IxRTT') or a succesful mobility activity (e.g., cause 'Inter-RAT Redirection'); or on transmission by the 
eNodeB/RN of UE CONTEXT RELEASE COMPLETE message for the UE context release initiated by the 
MME/DeNB with the exception of the corresponding UE CONTEXT RELEASE COMMAND message with 
"Cause" equal to 'Normal Release' ", 'detach', 'Handover Cancelled' or any 'cause' indicating a successful CS 
fallback (e.g., cause 'Redirection towards IxRTT') or a succesful mobility activity (e.g., cause 'Successful 
Handover', 'Inter-RAT Redirection' or 'S 1 Intra system Handover triggered') or on receipt by the eNB of a PATH 
SWITCH REQUEST ACKNOWLEDGE or PATH SWITCH REQUEST FAILED message by which some or 
all E-RABs in the corresponding PATH SWITCH REQUEST need to be released , or on transmission of a 
RESET ACKNOWLEDGE message to MME/DeNB; or on receipt of a RESET ACKNOWLEDGE message 
from MME/DeNB, if any of the UL or DL are considered active according to the definition used for "Number of 
active UEs" in TS 36.314. 

E-RABs with bursty flow are considered active when there is still data in the DL or UL buffer. E-RABs with 
continuous flow are always seen as active E-RABs in the context of this measurement.Each corresponding E- 
RAB to release is added to the relevant measurement per QCI. 

The possible QCIs are described in TS 36.413 [9]. The sum of all supported per QCI measurements shall equal 
the total number of E-RABs attempted to release when the E-RAB is active according to the definition of bursty 
flow/continuous flow. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

How to define for a particular QCI if the E-RAB is of type bursty flow or continuous flow is outside the scope of 
this document. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.RelActNbr.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Retainability KPI 'E-RAB Retainability' defined in [13] 

4.2.3 E-RAB modification 

4.2.3.1 Number of E-RABs attempted to modify the QoS parameter 

a) This measurement provides the number of E-RABs attempted to modify the QoS parameter. The measurement is 
split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On receipt by the eNodeB/RN of an E-RAB MODIFY REQUEST message, each E-RAB attempted to modify 
the QoS parameter is added to the relevant measurement per QCI, the possible QCIs are included in 

TS 36.413 [9]. The sum of all supported per QCI measurements shall equal the total number of E-RABs 
attempted to modify the QoS parameter. In case only a subset of per QCI measurements is supported, a sum 
subcounter will be provided first. 
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d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.ModQoSAttNbr.QC/ 
where QCI identifies the target E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.2.3.2 Number of E-RABs successfully modified the QoS parameter 

a) This measurement provides the number of E-RABs successfully modified the QoS parameter. The measurement 
is split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB MODIFY RESPONSE message, each E-RAB successfully 
modified the QoS parameter is added to the relevant measurement per QCI, the possible QCIs are included in 
TS 36.413 [9]. The sum of all supported per QCI measurements shall equal the total number of E-RABs 
successfully modified the QoS parameter. In case only a subset of per QCI measurements is supported, a sum 
subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.ModQoSSuccNbr.gC/ 
where QC/ identifies the target E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 



4.2.3.3 Number of E-RABs failed to modify the QoS parameter 

a) This measurement provides the number of E-RABs failed to be modified the QoS parameter. The measurement 
is split into subcounters per failure cause. 

b) CC 

c) On transmission by the eNodeB/RN of an E-RAB MODIFY RESPONSE message, each E-RAB failed to modify 
the QoS parameter is added to the relevant measurement per cause, the possible causes are included in 

TS 36.413 [9]. The sum of all supported per cause measurements shall equal the total number of E-RABs failed 
to modify the QoS parameter. In case only a subset of per cause measurements is supported, a sum subcounter 
will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.ModQoSFailNbr.CflMie 
where Cause identifies the cause resulting in the E-RAB Modify failure. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 



£75/ 



(3GPP TS 32.425 version 1 1 .3.0 Release 11) 26 ETSI TS 1 32 425 V1 1 .3.0 (201 2-1 1 ) 

h) EPS 

4.2.4 E-RAB activity 

4.2.4.1 In-session activity time for UE 

a) This measurement provides the aggregated active session time for UEs in a cell. 

b) CC 

c) Number of session seconds aggregated for UEs in a cell. 

For E-RABs with bursty flow, a UE is said to be 'in session' if any E-RAB data on a Data Radio Bearer (UL or 
DL) has been transferred during the last 100 ms. 

For E-RABs with continuous flow, the E-RAB (and the UE) is always seen as being 'in session' in the context 
of this measurement, and the session time is increased from the first data transmission on the E-RAB until 100 
ms after the last data transmission on the E-RAB. 

d) Each measurement is an integer value. 

e) ERAB.SessionTimeUE 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Retainability KPI 'E-RAB Retainability' defined in [13]. 



4.2.4.2 In-session activity time for E-RABs 

a) This measurement provides the aggregated active session time for E-RABs in a cell. The measurement is split 
into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) Number of s'in ession 'seconds aggregated for E-RABs with a certain QCI. , where 'in session' has the following 
definitions: 



- E-RABs with bursty flow is said to be 'in session' for a UE if any E-RAB data on any Data Radio Bearer 
(UL or DL) has been transferred during the last 100 ms for that QCI 

- E-RABs with continuous flow are always seen as being 'in session' in the context of this measurement, and the 
session time is increased from the first data transmission on the E-RAB until 100 ms after the last data 
transmission on the E-RAB. 

The possible QCIs are described in TS 36.413 [9]. The sum of all supported per QCI measurements shall equal 
the total session seconds. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

How to decide for a particular QCI if the E-RAB is of type continuous flow is outside the scope of this 
document. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.SessionTimeQCI.QC/ 
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where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Retainability KPI 'E-RAB Retainability' defined in [13]. 

4.2.5 E-RAB number 

4.2.5.1 Average Number of simultaneous E-RABs. 

a) This measurement provides the average number of simultaneous E-RABs. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval, the number of simultaneous E-RABs and 
then taking the arithmetic mean. The measurement is split into subcounters per QCI, and the possible QCIs are 
included in TS 36.413 [9]. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.UsageNbrMean.gC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.2.5.2 Maximum Number of simultaneous E-RABs. 

a) This measurement provides the maximum number of simultaneous E-RABs. The measurement is split into 
subcounters per E-RAB QoS level (QCI). 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval, the number of simultaneous E-RABs and 
then taking the maximum. The measurement is split into subcounters per QCI, and the possible QCIs are 
included in TS 36.413 [9]. In case only a subset of per QCI measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form ERAB.UsageNbrMax.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 
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4.3 Handover related measurements 

4.3.1 Intra-RAT Handovers 

4.3.1 .1 Intra-eNB/RN Handover related measurements 

4.3.1 .1 .1 Attempted outgoing intra-eNB/RN handovers per handover cause 

a) This measurement provides the number of attempted outgoing intra-eNB/RN handovers per handover cause. 

b) CC. 

c) Transmission of the RRCConnectionReconfiguration message by the eNB/RN to the UE triggering the intra- 
eNB/RN handover (see TS 36.331 [8]). Each RRCConnectionReconfiguration message transimtted is added to 
the relevant per handover cause measurement, the possible causes are included in TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing intra-eNB/RN 
handover events. In case only a subset of per cause measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.lntraEnbOutAtt.CflMie 

where Cause identifies the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .1 .2 Successful outgoing intra-eNB/RN handovers per handover cause 

a) This measurement provides the number of successful outgoing intra-eNB/RN handovers per handover cause. 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB/RN, indicating a successful outgoing intra-eNB/RN handover (see TS 36.331 [8]). Each 
RRCConnectionReconfigurationComplete message transimtted is added to the relevant per handover cause 
measurement, the possible causes are included in TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing intra-eNB/RN 
handover events. In case only a subset of per cause measurements is supported, a sum subcounter will be 
provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix 

e) HO.IntraEnbOutSucc.CflMse 

where Cause identifies the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.3.1 .1 .3 Attempted outgoing intra-DeNB handover preparations from DeNB cell to RN per 
handover cause 

a) This measurement provides the number of attempted outgoing intra-DeNB handover preparations from DeNB 
cell to RN per handover cause; this measurement is only applicable to DeNB. 

b) CC. 

c) Transmission of the X2AP message HANDOVER REQUEST from the DeNB to RN (see TS 36.423[10]), 
indicating the attempt of an outgoing intra-DeNB handover preparation from DeNB cell to RN, the forwarded 
X2AP message HANDOVER REQUEST for the handover from another RN, eNB or DeNB to the RN is 
exclusive, the measurement is only incemented by one for one handover in case the X2AP message 
HANDOVER REQUEST are sent to multiple RNs. Each attempted outgoing intra-DeNB handover preparation 
from DeNB cell to RN is added to the relevant per handover cause measurement, the possible causes are 
included in TS 36.413 [9]. The sum of all supported per cause measurements shall equal the total number of 
attempted outgoing intra-DeNB handover preparations from DeNB cell to RN. In case only a subset of per cause 
measurements is supported, a sum subcounter will be provided first. 

d) A single integer value. 

e) HO.IntraDenbOutPrepToRnAtt. CflMse 
where Cause identifies the cause for handover 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .1 .4 Attempted outgoing intra-DeNB handover executions from DeNB cell to RN per 
handover cause 

a) This measurement provides the number of attempted outgoing intra-eNB handovers from DeNB cell to RN per 
handover cause; this measurement is only applicable to DeNB. 

b) CC. 

c) Transmission of the RRC ConnectionReconfiguration message to UE triggering the handover from the DeNB to 
the RN, indicatingthe attempt of an outgoing intra-eNB handover from DeNB cell to RN (see TS 36.331 [8]). 
Each RRCConnectionReconfiguration message transimtted is added to the relevant per handover cause 
measurement, the possible causes are included in TS 36.413 [9]. The sum of all supported per cause 
measurements shall equal the total number of attempted outgoing intra-eNB handovers from DeNB cell to RN. 
In case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.IntraDenbOutToRnAtt. CflMie 

where Cause identifies the cause for handover 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .1 .5 Successful outgoing intra-DeNB handover executions from DeNB cell to RN per 
handover cause 

a) This measurement provides the number of successful outgoing intra-DeNB handovers from DeNB cell to RN per 
handover cause; this measurement is only applicable to DeNB. 
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b) CC. 

c) Receipt by the source DeNB of X2AP message UE CONTEXT RELEASE from the RN following a successful 
handover (see TS 36.423[10]), the forwarded X2AP message UE CONTEXT RELEASE for the handover from 
another RN, eNB or DeNB to the RN is exclusive. Each outgoing intra-DeNB handover from DeNB cell to RN 
is added to the relevant per handover cause measurement, the possible causes are included in TS 36.413 [9]. 
The sum of all supported per cause measurements shall equal the total number of succesful outgoing intra-eNB 
handovers from DeNB cell to RN. In case only a subset of per cause measurements is supported, a sum 
subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.IntraDenbOutToRnSucc.CflMse 

where Cause identifies the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .2 Inter-eNB Handover related measurements 

4.3.1 .2.1 Attempted outgoing inter-eNB handover preparations 

a) This measurement provides the number of attempted outgoing inter-eNB handover preparations, the forwarded 
handovers for RN in DeNB are exclusive. 

b) CC. 

c) Transmission of the X2AP message HANDOVER REQUEST from the source eNB to the target eNB (see TS 
36.423[10]), indicating the attempt of an outgoing inter-eNB handover preparation or on transmission of SI AP 
message HANDOVER REQUIRED to the MME (see TS 36.413 [9]), the forwarded X2AP message 
HANDOVER REQUEST and SlAP message HANDOVER REQUIRED for RN in DeNB are exclusive. 

d) A single integer value. 

e) HO.InterEnbOutPrepAtt 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .2.2 Attempted outgoing inter-eNB handover executions per handover cause 

a) This measurement provides the number of attempted outgoing inter-eNB handovers per handover cause. 

b) CC. 

c) Transmission of the RRC ConnectionReconfiguration message to UE triggering the handover from the source 
eNB to the target eNB, indicatingthe attempt of an outgoing inter-eNB handover (see TS 36.331 [8]). 

The sum of all supported per cause measurements shall equal the total number of outgoing inter-eNB handover 
event Each RRCConnectionReconfiguration message transimtted is added to the relevant per handover cause 
measurement, the possible causes are included in TS 36.413 [9]. In case only a subset of per cause measurements 
is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 
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e) HO.InterEnbOutAtt. CaMie 

where Cause identifies the cause for handover 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .2.3 Successful outgoing inter-eNB handover executions per handover cause 

a) This measurement provides the number of successful outgoing inter-eNB handovers per handover cause, the 
forwarded handovers for RN in DeNB are exclusive. 

b) CC. 

c) Receipt at the source eNB of UE CONTEXT RELEASE [10] over the X2 from the target eNB following a 
successful handover, or if handover is performed via SI, receipt of UE CONTEXT RELEASE COMMAND [9] 
at the source eNB following a successful handover, the forwarded X2AP UE CONTEXT RELEASE message 
and SlAP UE CONTEXT RELEASE COMMAND message for RN in DeNB are exclusive. Each X2AP UE 
CONTEXT RELEASE message or SlAP UE CONTEXT RELEASE COMMAND message received and 
counted is added to the relevant per handover cause measurement, the possible causes are included in 

TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing inter-eNB handover 

events. In case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.InterEnbOutSucc.CflM.ve 

where Cause identifies the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .3 Handover measurements on neighbour cell basis 

4.3.1 .3.1 Attempted outgoing handovers per handover cause 

a) This measurement provides the number of attempted outgoing handovers per handover cause and LTE target cell 
specific. 

b) CC. 

c) Transmission of the RRCConnection reconfiguration message to UE triggering the intra-RAT handover (see TS 
36.331 [8]). Each RRCConnectionReconfiguration message transimtted is added to the relevant per handover 
cause measurement, the possible causes are included in TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing handover events. In 
case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.OutAttTarget. CflMse 

where Cause identifies the cause for handover 

f) EUtranRelation 

g) Valid for packet switched traffic 
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h) EPS 

4.3.1 .3.2 Successful outgoing handovers per handover cause 

a) This measurement provides the number of successful outgoing handovers per handover cause and LTE target 
cell specific. 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB, indicating a successful outgoing intra-eNB handover (see TS 36.331 [8]), or receipt at the source eNB of 
UE CONTEXT RELEASE [10] over the X2 from the target eNB following a successful inter-eNB handover, or 
if handover is performed via S 1 , receipt of UE CONTEXT RELEASE COMMAND [9] at the source eNB 
following a successful inter-eNB handover. Each RRCConnectionReconfigurationComplete, X2AP UE 
CONTEXT RELEASE message or SlAP UE CONTEXT RELEASE COMMAND message received is added to 
the relevant per handover cause measurement, the possible causes are included in TS 36.413 [9]. The sum of all 
supported per cause measurements shall equal the total number of outgoing intra-RAT handover events. In case 
only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.OutSuccTarget.CflMse 

where Cause identifies the cause for handover. 

f) EUtranRelation 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .3.3 Number of handover failures related with MRO 

a) This measurement provides the number of outgoing handover related events that fail related with MRO. 
Handover related events include normal successful handovers and all failure events by which a UE in RRC 
connected state changes its serving cell without following a normal handover. Different MRO failure cases are 
found in [12]. The measurement includes separate counters for the number of handover failures classified as 'too 
early', 'too late' and 'to wrong cell'. The measurement for the too late handover is split to subcounters indicating 
the threshold of the serving cell itself was not crossed and the threshold of the neighbour cell was not crossed in 
UE measurements before handover in case the handover is triggered by more than one threshold of the 
measurement report triggering events, the subcounters are only needed if more than one threshold of the 
measurement report triggering events is used and using single or multiple thresholds is vendor specific. 

b) CC 

c) The measurements of too early handovers, too late handovers and to wrong cell handovers are obtained 
respectively by accumulating the number of failure events related to handover which are identified by the eNB 
according to the definitions in TS 36.300 [12]. 

Besides being added to the measurement of total too late handovers, each too late handover (identified by the 
eNB according to the definitions in TS 36.300 [12]) is also added to the relevant subcounter indicating the 
threshold of the serving cell itself configured in the measurement report triggering events (see 36.331 [18]) was 
not crossed or the threshold of the neighbour cell configured in the measurement report triggering events was not 
crossed if more than one threshold triggering a measurement report is configured to the UEs for the involved 
neighbour relation and the following UE measurement results are available for both cells involved in the too late 
handover 

- rsrpResult of 'measResultLastServCell' and 

- rsrpResult of the subject neighbour cell in 'measResultNeighCells' 
in 

a) the 'RLE report' IE in the received RRC message 'UEInformationResponse' (see 36.331 [18]), in case both 
cells involved in the too late handover belong to the same eNB, 

or 

b) the 'UE RLE Report Container' IE in the received X2 message 'RLE Indication', in case the cells involved in 
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the too late handover belong to different eNBs. 

The uncrossed threshold (of the serving itself and the neighbour) is identified by comparing the UE measurement 
results above with the configured thresholds (adding the corresponding hysteresis, see 36.331 [18]) of the 
measurement report triggering events, 

if the threshold of the serving cell itself was not crossed, the observed too late handover is then added to the 
subcounter (HO.OutFail.TooLateOwnNotCrossed) indicating the threshold of the serving cell was not crossed 

if the threshold of the neighbor cell itself was not crossed, the observed too late handover is then added to the 
subcounter (HO.OutFail.TooLateNeighborNotCrossed) indicating the threshold of the neighbour cell was not 
crossed 

if the thresholds of both the serving cell itself and the neighbour cell were not crossed, then this too late 
handover is added to both subcounters (HO.OutFail.TooLateOwnNotCrossed and 

HO.OutPail.TooLateNeighborNotCrossed) indicating the threshold of serving cell itself was not crossed and the 
threshold of the neighbour cell was not crossed 

if no threshold was not crossed, then this handover is only added to the measurement of total too late 
handovers but not to the subcounter indicating the threshold of the serving cell itself was not crossed or the 
threshold of the neighbour cell was not crossed. 

If only one threshold triggring the measurement report is configured to the UEs for the involved neighbour 
relation or the UE measurements above are not available, the observed too late handover is only added to the 
measurement of total too late handovers but not to the subcounter indicating the threshold of the serving cell 
itself was not crossed or the threshold of the neighbour cell was not crossed. 

d) Each measurement is an integer value. 

e) The measurements are named 

HO.OutFail.TooEarly 

HO.OutFail.TooLate 

Which indicates the total number of too late handovers identified by the eNB according to the definitions in TS 

36.300 [12]. 

HO.OutFail.TooLateOwnNotCrossed 

Which indicates the number of too late handovers for which the threshold of the serving cell itself was not 

crossed. HO.OutFail.TooLateNeighborNotCrossed 

Which indicates the number of too late handovers for which the threshold of the neighbor cell was not crossed. 

HO.OutFail.ToWrongCell 

f) EUtranRelation 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .4 Intra- / Inter-frequency Handover related measurements 

4.3.1 .4.1 Attempted outgoing intra-frequency handovers 

a) This measurement provides the number of attempted outgoing intra-frequency handovers. 

b) CC. 

c) Transmission of the RRCConnectionReconfiguration message by the eNB/RN to UE triggering the handover, 
indicating the attempt of an outgoing intra-frequency handover (see TS 36.331 [8]). 

d) A single integer value. 

e) HO.IntraFreqOutAtt. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
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h) EPS 

4.3.1 .4.2 Successful outgoing intra-frequency handovers 

a) This measurement provides the number of successful outgoing intra-frequency handovers. 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB/RN, indicating a successful outgoing intra-eNB/RN intra-frequency handover (see TS 36.331 [8]), orreceipt 
at the source eNB/RN of UE CONTEXT RELEASE [10] over the X2 from the target eNB or DeNB following a 
successful inter-eNB intra-frequency handover, or if handover is performed via S 1 , receipt of UE CONTEXT 
RELEASE COMMAND [9] at the source eNB following a successful inter-eNB intra-frequency handover. 

d) A single integer value. 

e) HO.IntraFreqOutSucc 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .4.3 Attempted outgoing inter-frequency handovers - gap-assisted measurement 

a) This measurement provides the number of attempted outgoing inter-frequency handovers, when measurement 
gaps are used [12]. 

b) CC. 

c) Transmission of the RRCConnectionReconfiguration message by the eNB/RN to UE triggering the handover, 
indicating the attempt of an outgoing inter-frequency handover when measurement gaps are used (see TS 
36.331 [8]). 

d) A single integer value. 

e) HO.InterFreqMeasGapOutAtt 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .4.4 Successful outgoing inter-frequency handovers - gap-assisted measurement 

a) This measurement provides the number of successful outgoing inter-frequency handovers, when measurement 
gaps are used [12]. 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB/RN, indicating a successful outgoing intra-eNB/RN inter-frequency handover when measurement gaps are 
used (see TS 36.331 [8]), or receipt at the source eNB/RN of UE CONTEXT RELEASE [10] over the X2 from 
the target eNB or DeNB following a successful inter-frequency handover when measurement gaps are used, or if 
handover is performed via SI, receipt of UE CONTEXT RELEASE COMMAND [9] at the source eNB 
following a successful inter-frequency handover when measurement gaps are used. 

d) A single integer value. 

e) HO.InterFreqMeasGapOutSucc 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .4.5 Attempted outgoing inter-frequency handovers - non gap-assisted measurement 

a) This measurement provides the number of attempted outgoing inter-frequency handovers, when measurement 
gaps are not used [12]. 

b) CC. 

c) Transmission of the RRCConnectionReconfiguration message by the eNB/RN to UE triggering the handover, 
indicating the attempt of an outgoing inter-frequency handover when measurement gaps are not used (see TS 
36.331 [8]). 

d) A single integer value. 

e) HO.InterFreqNoMeasGapOutAtt 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .4.6 Successful outgoing inter-frequency handovers - non gap-assisted measurement 

a) This measurement provides the number of successful outgoing inter-frequency handovers, when measurement 
gaps are not used [12]. 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB/RN, indicating a successful outgoing intra-eNB/RN inter-frequency handover when measurement gaps are 
not used (see TS 36.331 [8]), or receipt at the source eNB/RN of UE CONTEXT RELEASE [10] over the X2 
from the target eNB or from DeNB following a successful inter-frequency handover when measurement gaps are 
not used, or if handover is performed via SI, receipt of UE CONTEXT RELEASE COMMAND [9] at the source 
eNB following a successful inter-frequency handover when measurement gaps are not used. 

d) A single integer value. 

e) HO.InterFreqNoMeasGapOutSucc 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .5 Handover related measurements for DRX / non-DRX 

4.3.1 .5.1 Attempted outgoing handovers with DRX 

a) This measurement provides the number of attempted outgoing handovers, when DRX is used (for DRX see 

[12]). 

b) CC. 
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c) Transmission of the RRCConnectionReconfiguration message to UE triggering the handover, indicating the 
attempt of an outgoing handover when DRX is used (see TS 36.331 [8]). 

d) A single integer value. 

e) HO.DrxOutAtt 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1.5.2 Successful outgoing handovers with DRX 

a) This measurement provides the number of successful outgoing handovers, when DRX is used (for DRX see 
[12]). 

b) CC. 

c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB, indicating a successful outgoing intra-eNB handover when DRX is used (see TS 36.331 [8]), or receipt at 
the source eNB of UE CONTEXT RELEASE [10] over the X2 from the target eNB following a successful 
handover when DRX is used, or if handover is performed via S 1 , receipt of UE CONTEXT RELEASE 
COMMAND[9] at the source eNB following a successful handover when DRX is used. 

d) A single integer value. 

e) HO.DrxOutSucc 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .5.3 Attempted outgoing handovers non-DRX 

a) This measurement provides the number of attempted outgoing handovers, when DRX is not used (for DRX see 
[12]). 

b) CC. 

c) Transmission of the RRCConnectionReconfiguration message to UE triggering the handover, indicating the 
attempt of an outgoing handover when DRX is not used (see TS 36.331 [8]). 

d) A single integer value. 

e) HO.NoDrxOutAtt. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1.5.4 Successful outgoing handovers non-DRX 

a) This measurement provides the number of successful outgoing handovers, when DRX is not used (for DRX see 
[12]). 

b) CC. 
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c) Receipt of a RRC message RRCConnectionReconfigurationComplete sent from the UE to the target (=source) 
eNB, indicating a successful outgoing intra-eNB handover when DRX is not used (see TS 36.331 [8]) when 
DRX is not used, or receipt at the source eNB of UE CONTEXT RELEASE [10] over the X2 from the target 
eNB following a successful handover when DRX is not used, or if handover is performed via S 1 , receipt of UE 
CONTEXT RELEASE COMMAND[9] at the source eNB following a successful handoverwhen DRX is not 
used. 

d) A single integer value. 

e) HO.NoDrxOutSucc 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .6 Handover to cells outside the RN related measurements 

4.3.1 .6.1 Attempted preparations of outgoing handovers to the cells outside the RN 

a) This measurement provides the number of attempted preparations of outgoing handovers to the cells outside the 
RN. 

b) CC. 

c) Transmission of the X2AP message HANDOVER REQUEST by the RN to the DeNB (see TS 36.423 [10]), 
indicating the attempt of an outgoing handover preparation to the cells outside the RN. 

d) A single integer value. 

e) HO.OutRNOutPrepAtt 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .6.2 Attempted executions of outgoing handover to the cells outside the RN per 
handover cause 

a) This measurement provides the number of attempted executions of outgoing handovers to the cells outside the 
RN per handover cause. 

b) CC. 

c) Transmission of the RRC ConnectionReconfiguration message by the RN to UE triggering the handover from the 
RN to the cell outside the RN, indicatingthe attempt of an outgoing handover to the cell outside the RN(see TS 
36.331 [8]). 

The sum of all supported per cause measurements shall equal the total number of attempted executions of 
outgoing handovers to the cell outside the RN. Each RRCConnectionReconfiguration message transimtted is 
added to the relevant per handover cause measurement, the possible causes are included in TS 36.413 [9]. In case 
only a subset of per cause measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.OutRNOutAtt.CaM.se 

where Cause identifies the cause for handover 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .6.3 Successful executions of outgoing handover to the cells outside the RN per 

handover cause 

a) This measurement provides the number of successful executions of outgoing handovers to the cells outside the 
RN per handover cause. 

b) CC. 

c) Receipt at the RN of UE CONTEXT RELEASE [10] over the X2 from the DeNB following a successful 
handover. Each X2AP UE CONTEXT RELEASE message received is added to the relevant per handover cause 
measurement, the possible causes are included in TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of executions of outgoing 
handovers to the cells outside the RN. In case only a subset of per cause measurements is supported, a sum 
subcounter will be provided first. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.InterRNOutSucc. CflMie 

where Cause identifies the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.3.1 .7 Handover triggering measurements 

4.3.1 .7.1 Average quality of the serving cell when HO is triggered 

a) This measurement provides the average quality of the serving cell reported in the UE measurement reports that 
triggered HO. The average is computed over all measurement reports that triggered HO received during the 
measurement granularity period. Separate measurement is produced for each measurement quantity {RSRP, 
RSRQ}. 

b) DER(n=l) 

c) For each UtranRelation, this measurement is obtained by accumulating the value (linear value converted from 
dbm unit) of the quality of the serving (source) cell (RSRP and RSRQ) in the UE measurement report causing 
HO on the UtranRelation, and dividing the accumulated value by the number of HO occurrence on the 
UtranRelation at the end of granularity period, and converting the value back to dbm unit from linear value. 
Separate measurement is provided for RSRP and for RSRQ. 

d) Each measurement is asingle integer value in dBm (RSRP) or dB (RSRQ) 

e) HO.SrcCellQual.RSRP 
HO.SrcCellQual.RSRQ 

f) EUtranRelation 

g) Valid for packet switched traffic 
h) EPS 
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4.3.1 .7.2 Average quality of the neighboring cell when HO is triggered 

a) This measurement provides the average quality of the neigbor cell that triggered HO (target HO cell) reported in 
the UE measurement reports. The average is computed over all measurement reports that triggered HO during 
the measurement granularity period. Separate measurement is produced for each measurement quantity {RSRP, 
RSRQ}. 

b) DER(n=l) 

c) For each UtranRelation, this measurement is obtained by accumulating the value (linear value converted from 
dbm unit) of the quality of neighbor (target) cell (RSRP, RSRQ) in the UE measurement report causing HO to 
the subject neighbor (target) cell on the UtranRelation, and dividing the accumulated value by the number of HO 
occurrence on the UtranRelation at the end of granularity period, and converting the value back to dbm unit from 
linear value. Separate measurement is provided for RSRP and for RSRQ. 

d) Each measurement is a single integer value in dBm (RSRP) or dB (RSRQ) 

e) HO.TrgtCellQual.RSRP 
HO.TrgtCellQual.RSRQ 

f) EUtranRelation 

g) Valid for packet switched traffic 
h) EPS 

4.3.2 Inter-RAT Handovers 

4.3.2.1 Measurements related to inter-RAT Handovers - target cell of 3GPP and 

non-3GPP network technology 

4.3.2.1 .1 Attempted outgoing inter-RAT handovers per handover cause 

a) This measurement provides the number of attempted outgoing inter-RAT handovers per cause and target cell 
specific. 

b) CC. 

c) Transmission of the MobilityFromEUTRACommand message or the HandoverFromEUTRAPreparationRequest 
message from the serving eNB/RN to the UE indicating the attempt of an outgoing handover from EUTRAN to 
UTRAN or to GERAN or to CDMA2000 (see TS 36.331 [8]). Each MobilityFromEUTRACommand message or 
HandoverFromEUTRAPreparationRequest message transmitted is added to the relevant per handover cause 
measurement, the possible causes are included in TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing inter-RAT handover 
events. In case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 
All IRAT handovers to the neighbouring cells in non-eUTRAN networks are measured. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.IartOutAtt. CflMie 

where Cause identifies the cause for handover 

f) EUtranCellFDD 
EUtranCellTDD 
GSMRelation 
UTRANRelation 
CDMA2000Relation 

g) Valid for packet switched traffic 
h) EPS 
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4.3.2.1 .2 Successful outgoing inter-RAT handovers per handover cause 

a) This measurement provides the number of successful outgoing inter-RAT handovers per cause target cell 
specific. 

b) CC. 

c) Receipt of a SlAP message UE CONTEXT RELEASE COMMAND sent from the MME/DeNB to the source 
eNB, indicating a successful IRAT handover (see TS 36.413 [9]). Each UE CONTEXT RELEASE COMMAND 
message received is added to the relevant per handover cause measurement, the possible causes are included in 
TS 36.413 [9]. 

The sum of all supported per cause measurements shall equal the total number of outgoing inter-RAT handover 
events. In case only a subset of per cause measurements is supported, a sum subcounter will be provided first. 
All IRAT handovers to the neighbouring cells in non-eUTRAN are measured. 

d) Each measurement is an integer value. The number of measurements is equal to the number of causes supported 
plus a possible sum value identified by the .sum suffix. 

e) HO.IartOutSucc.CflMie 

where Cause indicating the cause for handover. 

f) EUtranCellFDD 
EUtranCellTDD 
GSMRelation 
UTRANRelation 
CDMA2000Relation 

g) Valid for packet switched traffic 
h) EPS 

4.3.2.1 .3 Number of outgoing unnecessary handovers related with inter-RAT MRO 

a) This measurement provides the number of outgoing unnecessary handovers to another RAT from E-UTRAN 
related with inter-RAT MRO. 

b) CC 

c) The measurement is obtained by accumulating the number of outgoing unnecessary handovers to anther RAT 
from E-UTRAN according to the definitions in TS 36.300 [12] and TS 36.413[9]. 

d) A single integer value. 

e) HO.IratOutUnnecessaryFromEutran 

f) GSMRelation 
UTRANRelation 
CDMA2000Relation 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the PM for inter-RAT MRO defined in TS 32.522[15]. 
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4.4 Cell level radio bearer QoS related measurements 
4.4.1 Cell PDCP SDU bit-rate 

4.4.1 .1 Average DL cell PDCP SDU bit-rate 

a) This measurement provides the average cell bit-rate of PDCP SDUs on the downlink. This represents the 
ingress rate of user plane traffic to the eNodeB/RN (via X2 or S 1). The measurement is split into subcounters 
per E-RAB QoS level (QCI). 

b) CC 

c) This measurement is obtained by accumulating the number of bits entering the eNodeB/RN, and then dividing 
the sum by the measurement period . The measurement is performed at the PDCP SDU level. PDCP SDUs that 
are forwarded over the X2/S 1 to another eNodeB during handover shall be deducted from the bit count - if this 
results in a negative bit count the bit count shall be set to zero. Separate counters are maintained for each QCI. 
The sum of all supported per QCI measurements shall equal the total DL cell PDCP SDU bit-rate. In case only 
a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value representing the bit-rate measured in kb/s. The number of measurements is 
equal to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form DRB.PdcpSduBitrateDl.QC/ 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.1 .2 Average UL cell PDCP SDU bit-rate 

a) This measurement provides the average cell bit-rate of PDCP SDUs on the uplink. This represents successful 
transmissions of user plane traffic; control signalling and retransmissions are excluded from this measure. The 
measurement is split into subcounters per E-RAB QoS level (QCI). 

b) CC 

c) This measurement is obtained by accumulating the number of bits leaving the eNodeB/RN on the X2 or S 1 
interface, and then dividing the sum by the measurement period. The measurement is performed at the PDCP 
SDU level. PDCP SDUs that were not received over the air interface in the cell (but were forwarded from 
another eNodeB during handover) are excluded from the count. Separate counters are maintained for each QCI. 
The sum of all supported per QCI measurements shall equal the total UL cell PDCP SDU bit-rate. In case only 
a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value representing the bit-rate measured in kb/s. The number of measurements is 
equal to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form DRB. PdcpSduBitrateUl.QC/ 
where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.4.1 .3 Maximum DL cell PDCP SDU bit-rate 

a) This measurement provides the maximum cell bit-rate of PDCP SDUs on the downlink. This represents the 
maximum ingress rate of user plane traffic to the eNodeB/RN (via X2 or SI). This is a sum counter measured 
across all QCIs. 

b) SI 

c) This measurement is obtained by sampling at pre-defined intervals the DL cell PDCP SDU bit-rate summed 
across all QCIs (see clause 4.4.1.1), and then taking the arithmetic maximum of these samples. 

d) A single integer value representing the maximum bit-rate measured in kb/s. 

e) DRB.PdcpSduBitrateDlMax 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.1 .4 Maximum UL cell PDCP SDU bit-rate 

a) This measurement provides the maximum cell bit-rate of PDCP SDUs measured on the uplink. This represents 
successful transmissions of user plane traffic; control signalling and retransmissions are excluded from this 
measure. This is a sum counter measured across all QCIs. 

b) SI 

c) The measurement is obtained by sampling at pre-defined intervals the UL cell PDCP SDU bit-rate summed 
across all QCIs (see clause 4.4.1.2), and then taking the arithmetic maximum of these samples. 

d) A single integer value representing the maximum bit-rate measured in kb/s. 

e) DRB.PdcpSduBitrateUlMax 

f) EUti-anCellFDD 
EUti-anCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.1 .5 Average DL cell control plane PDCP SDU bit-rate 

i) This measurement provides the average cell bit-rate of control plane PDCP SDUs on the downlink. 

j) cc. 

k) This measurement is obtained by accumulating the number of received control plane PDCP SDU bits by the 
eNodeB/RN, including the control plane PDCP SDU bits received from S 1 and RRC SAP, and then dividing the 
sum by the measurement period. 

1) An single integer value in kb/s. 

m) SRB.PdcpSduBitrateDl 

n) EUtranCellFDD 
EUtranCellTDD 

o) Valid for packet switching. 

p) EPS 
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4.4.1 .6 Average UL cell control plane PDCP SDL) bit-rate 

a) This measurement provides the average cell bit-rate of control plane PDCP SDUs on the uplink. 
This represents successful transmissions of control plane traffic; 

b) CC. 

c) This measurement is obtained by accumulating the number of transmitted uplink control plane PDCP SDU bits 
by the eNodeB/RN, and then dividing the sum by the measurement period. 

d) An single integer value in kb/s. 

e) SRB.PdcpSduBitrateUl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.4.2 Active UEs 

4.4.2.1 Average number of active UEs on the DL 

a) This measurement provides the average number of UEs that have DTCH data queued on the downlink. The 
measurement is split into subcounters per E-RAB QoS level (QCI). For an eNodeB serving one or more RNs, the 
measurement refers to the number of active UEs connected directly to the eNodeB, excluding RNs. The 
measurement is also apphcable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 

e) The measurement name has the form 
DRB.UEActiveDl.eC/ 

where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.2.2 Average number of active UEs on the UL 

a) This measurement provides the average number of UEs that have DTCH data queued on the uplink. The 
measurement is split into subcounters per E-RAB QoS level (QCI). For an eNodeB serving one or more RNs, the 
measurement refers to the number of active UEs connected directly to the eNodeB, excluding RNs. The 
measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. 

d) Each measurement is an integer value. The number of measurements is equal to the number of QCIs plus a 
possible sum value identified by the .sum suffix. 
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e) The measurement name has the form 
DRB.UEActiveUl.eC/ 

where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.3 Packet Delay and Drop Rate 

4.4.3.1 Average DL PDCP SDU delay 

a) This measurement provides the average (arithmetic mean) PDCP SDU delay on the downlink. The 
measurement is split into subcounters per E-RAB QoS level (QCI). If there is one or more RNs served in a cell, 
for that cell the eNodeB performs each measurement separately for packets transmitted between the eNodeB and 
UEs and for packets transmitted between the E-UTRAN and RNs. The measurement is also applicable to RNs. 

b) DER(n=l) 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. 

d) Each measurement is an integer value representing the mean delay in ms. The number of measurements is equal 
to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form 

DRB.PdcpSduDelayDl.gC/, which indicates the PDCP SDU delay between the eNodeB (or RN) and UE 
DRB.PdcpSduDelayDlRN.eC/ which indicates the PDCP SDU delay between the E-UTRAN and RN. 
where gC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.3.2 DL PDCP SDU drop rate 

a) This measurement provides the fraction of IP packets (PDCP SDUs) which are dropped on the downlink. Only 
user -plane traffic (DTCH) is considered. A dropped packet is one whose context is removed from the 
eNodeB/RN without any part of it having been transmitted on the air interface. Packets discarded during 
handover are excluded from the count. The measurement is split into subcounters per E-RAB QoS level (QCI). 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. In case only a subset of per QCI measurements is supported, a drop rate subcounter 
calculated across all QCIs will be provided first. 

d) Each measurement is an integer value representing the drop rate multiplied by 1E6. The number of 
measurements is equal to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form DRB.PdcpSduDropRateDl.QC/ 
where QC/ identifies the target E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.4.4 Packet loss rate 

4.4.4.1 DL PDCP SDU air interface loss rate 

a) This measurement provides the fraction of IP packets (PDCP SDUs) which are lost (not successfully transmitted) 
on the downlink air interface. Only user-plane traffic (DTCH) is considered. A lost packet is one whose context 
is removed from the eNodeB/RN after an attempt has been made to transmit part or all of the packet on the air 
interface but the whole packet has not been successfully transmitted. The measurement is split into subcounters 
per E-RAB QoS level (QCI). The packets transmitted between the eNodeB (or RN) and UEs and the packets 
transmitted between E-UTRAN and RN are counted seperately. The measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. In case only a subset of per QCI measurements is supported, a loss rate subcounter 
calculated across all QCIs will be provided first. 

d) Each measurement is an integer value representing the air interface loss rate multiplied by 1E6. The number of 
measurements is equal to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form 

DRB. PdcpSduAirLossRateDl.QC/, which indicates the DL PDCP SDU air interface loss rate between the 
eNodeB (or RN) and UE 

DRB. PdcpSduAirLossRateDlRN.QC/, which indicates the DL PDCP SDU air interface loss rate between the 

E-UTRAN and RN. 

where QC/ identifies the target E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.4.4.2 UL PDCP SDU loss rate 

a) This measurement provides the fraction of IP packets (PDCP SDUs) which are lost (not successfully received) 
on the uplink. Only user-plane traffic (DTCH) and only PDCP SDUs that have entered PDCP (and given a 
PDCP sequence number) are considered. The measurement is split into subcounters per E-RAB QoS level 
(QCI). The packets transmitted between the eNodeB and UEs and the packets transmitted between E-UTRAN 
and RN are counted seperately. The measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. In case only a subset of per QCI measurements is supported, a loss rate subcounter 
calculated across all QCIs will be provided first. 

d) Each measurement is an integer value representing the loss rate multiplied by 1E6. The number of measurements 
is equal to the number of QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form DRB.PdcpSduLossRateUl.QC//, which indicates the UL PDCP SDU loss 
rate between the eNodeB (or RN) and UE 

DRB.PdcpSduLossRateUlRN.eC/, which indicates the UL PDCP SDU loss rate between the E-UTRAN and RN. 
where QC/ identifies the target E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.4.5 IP Latency measurements 
4.4.5.1 IP Latency in DL, E-RAB level 

a) This measurement provides IP Latency in DL on E-RAB level. 

b) CC 

c) This measurement is obtained by the following formula for E-RABs 

LatTime 
LatS ample 

LatTime is obtained by accumulating the time T for E-RABs 

T — t —t \ms\ 

first part of data volume transmitted data received L J 

The sample of 'T' is made for the new arrived IP data block (PDCP SDU) when there is no other prior data to be 
transmitted to the same UE in the eNodeB/RN . 

LatSample is obtained by accumulating the number of Latency samples taken on the E-RAB level 

The measurement is split into subcounters per E-RAB QoS level (QCI). 

d) Each measurement is an integer value representing the time in ms. The number of measurements is equal to the 
number of QCI s. 

e) The measurement name has the form DRB.IpLateDl.QC/ 
where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Integrity KPI 'E-UTRAN IP Latency' defined in [13] 

4.4.6 IP Throughput measurements 
4.4.6.1 IP Throughput in DL 

a) This measurement provides IP throughput in downlink. For an eNodeB serving one or more RNs, packets 
transmitted between the E-UTRAN and RNs are excluded, i.e., only packets transmitted between the eNodeB (or 
RN) and UEs are counted. The measurement is also applicable to RN. 

b) DER(N=1) 

c) This measurement is obtained according to the following formula based on the 'ThpVolDl' and 'ThpTimeDl' 
defined for the 'Scheduled IP Throughput in DL' in 3GPP TS 36.314 [1 1] for each QCI. 

^ ^ ThpVolDl 



//V y ThpTimeDl >0, .^S= x\mQ{kbits I s^ 

2_j Z^ ThpTimeDl 



UEs 



If Z Z ThpTimeDl = 0, {kbits I s^ 



d) Each measurement is a real value representing the throughput in kbits/s. The number of measurements is equal to 
the number of QCIs. 
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e) The measurement name has the form 
DRB.IPThpDl.eC/ 

where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Integrity KPI 'E-UTRAN IP Throughput' defined in [13]. 

4.4.6.2 IP Throughput in UL 

a) This measurement provides IP throughput in uplink. For an eNodeB serving one or more RNs, packets 
transmitted between the E-UTRAN and RNs are excluded, i.e., only packets transmitted between the eNodeB (or 
RN) and UEs are counted. The measurement is also applicable to RN 

b) DER(N=1) 

c) This measurement is obtained according to the following formula based on the 'ThpVolUl' and 'ThpTimeUl' 
defined for the 'Scheduled IP Throughput inUL' in 3GPP TS 36.314 [11] for each QCI. 

^ ^ ThpVolUl 



//V y ThpTimeUl > 0, ^^^^ ^\mQ{kbits I s^ 

2_, z_i ThpTimeUl 



UEs 

UEs 

If ^ ^ ThpTimeUl = 0, {kbits Is] 

UEs 

d) Each measurement is a real value representing the volume in kbits. The number of measurements is equal to the 
number of QCIs. 

e) The measurement name has the form 
DRB.IPThpUl.eC/ 

where eC"/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Integrity KPI 'E-UTRAN IP Throughput' defined in [13]. 

4.5 Radio resource utilization related measurements 
4.5.1 DL PRB Usage for traffic 

a) This measurement provides the usage (in percentage) of physical resource blocks (PRBs) on the downlink for 
DTCH traffic. The measurement is split into subcounters per E-RAB QoS level (QCI). If there is one or more 
RNs served in a cell, for that cell the eNodeB performs PRB usage measurements separately for all traffic 
(including transmissions to/from RNs and UEs directly connected to the eNodeB) and for RN traffic. The 
measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. The sum of all supported per QCI measurements shall equal the total PRB usage for 
DTCH. In case only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 
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d) Each measurement is an integer value from to 100. The number of measurements is equal to the number of 
QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form 

RRU.PrbDl.QC/, which indicats the DL PRB Usage for all traffic 
RRU.PrbDlRN.eC/, which indicates the DL PRB Usage for the RN traffic 
where QC/ identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 



4.5.2 UL PRB Usage for traffic 



a) This measurement provides the usage (in percentage) of physical resource blocks (PRBs) on the uplink for 
DTCH traffic. The measurement is split into subcounters per E-RAB QoS level (QCI). If there is one or more 
RNs served in a cell, for that cell the eNodeB performs PRB usage measurements separately for all traffic 
(including transmissions to/from RNs and UEs directly connected to the eNodeB) and for RN traffic. The 
measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. Separate counters are 
maintained for each QCI. The sum of all supported per QCI measurements shall equal the total PRB usage for 
DTCH. In case only a subset of per QCI measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value from to 100. The number of measurements is equal to the number of 
QCIs plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form 

RRU.PrbUl.QC/, which indicats the UL PRB Usage for all traffic 
RRU.PrbUlRN.eC/, which indicates the UL PRB Usage for the RN traffic 
where QCI identifies the E-RAB level quality of service class. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 



4.5.3 DL Total PRB Usage 



a) This measurement provides the total usage (in percentage) of physical resource blocks (PRBs) on the downlink 
for any purpose. If there is one or more RNs served in a cell, for that cell the eNodeB performs PRB usage 
measurements separately for all traffic(including transmissions to/from RNs and UEs directly connected to the 
eNodeB) and for RN traffic. The measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. 

d) A single integer value from to 100. 

e) RRU.PrbTotDl, which indicats the DL PRB Usage for all traffic 
RRU.PrbTotDlRN, which indicates the DL PRB Usage for the RN traffic 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
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h) EPS 



4.5.4 UL Total PRB Usage 



a) This measurement provides the total usage (in percentage) of physical resource blocks (PRBs) on the uplink for 
any purpose. If there is one or more RNs served in a cell, for that cell the eNodeB performs PRB usage 
measurements separately for all traffic (including transmissions to/from RNs and UEs directly connected to the 
eNodeB) and for RN traffic. The measurement is also applicable to RNs. 

b) SI 

c) This measurement is obtained according to the definition in 3GPP TS 36.314 [11]. 

d) A single integer value from to 100. 

e) RRU.PrbTotUl, which indicats the UL PRB Usage for all traffic 
RRU.PrbTotUlRN, which indicates the UL PRB Usage for the RN traffic 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.5 RACH Usage 

4.5.5.1 Mean number of RACH preambles received 

a) This measurement provides the mean number of RACH preambles received in a cell in one second. Separate 
counts are provided for dedicated preambles, randomly chosen preambles in group A (aka 'low range') and 
randomly chosen preambles in group B (aka 'high range'). 

b) Gauge 

c) This measurement is obtained according to the definition in 36.314 [11]. 

d) Each measurement is an integer value. 

e) RRU.RachPreambleDedMean 
RRU.RachPreambleAMean 
RRU.RachPreambleBMean 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.5.2 Distribution of RACH preambles sent 

a) This measurement provides the distribution of number of RACH preambles sent by the UE as reported by the 
UEs inside the UEInformationResponse message 

b) CC 

c) This measurement is obtained by incrementing the measurement bin corresponding to the value of IE 
numberOfPreamblesSent-r9 ([8] clause 6.2.2) reported by UE inside UEInformationResponse message. The 
measurement is incremented each time a UEInformationResponse message containing rach-Report-r9 IE is 
received. 
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d) Each measurement is an integer value. 

e) RRU.RachPreambleDist.BinX 

where BinX represents the bin. 

Note: Number of bins and the range for each bin is left to implementation. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.5.3 Distribution of RACH access delay 

a) This measurement provides the distribution of number of the time before UEs in a cell achieve a successful 
attach. The RACH access delay is the time from when a UE sends its first Random Access Preamble until the 
UE receives the Random Access Response. 

b) CC 

c) This measurement is obtained by incrementing the measurement bin corresponding to the access delay 
experienced by the UE. The access delay is calculated based upon the value of IE numberOfPreamblesSent and 
IE contentionDetected reported by UE inside UEInformationResponse message ([8] clause 6.2.2). The 
measurement is incremented each time a UEInformationResponse message containing rach-Report-r9 IE is 
received. 

d) Each measurement is an integer value. 

e) RRU.RachAccessDelayDist.BinX 

where BinX represents the bin. 

Note: Number of bins and the range for each bin is left to implementation. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.5.4 Percentage of contentious RACH attempts 

a) This measurement provides the percentage of UEInformationResponse messages received within the 
measurement granularity interval with contentionDetected IE set to TRUE. 

b) SI 

c) When UEInformationResponse message ([8] clause 6.2.1) continaing rachReport-r9 IE is received the 
measurement is updated. 

d) Percentage 

e) RRU.RachContentionReported 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.5.5.5 Number of UE RACH reports received 

a) This measurement provides the number of UEInformationResponse messages received within the measurement 
granularity interval continaing rachReport-r9 IE. 

b) CC 

c) When UEInformationResponse message ([8] clause 6.2.1) continaing rachReport-r9 IE is received the 
measurement is incremented by one. 

d) Single integer value 

e) RRU.RachReportCount 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.5.6 Percentage of time when all dedicated RACH preambles are used 

a) This measurement provides the percentage of time when all dedicated RACH preambles are assigned to UEs. 

b) SI 

c) During each measurement granularity interval the percentage of time during which all dedicated RACH 
preambles were assigned to UEs is computed. 

d) Percentage 

e) RRU.RachDedicatedPreamblesAssigned 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.6 Cell Unavailable Time 

a) This measurement provides the length of time the cell has been unavailable for each cause. 

b) DER(n=l) 

c) This measurement is obtained by accumulating the time periods when the cell is unavailable per cause. The 
possible cause could be 'manual intervention', 'fault' and 'energy saving'. The sum of all supported per cause 
measurements shall equal the total time periods of cell unavailability. In case only a subset of per cause 
measurements is supported, a sum subcounter will be provided first. 

d) Each measurement is an integer value (in seconds). The number of measurements is equal to the number of 
supported causes plus a possible sum value identified by the .sum suffix. 

e) The measurement name has the form RRU.CellUnavailableTime. cause. 
Where cause identifies the cause resuling in cell unavailable. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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i) This measurement is to support KPI 'E-UTRAN Cell Availability' defined in [13]. 

4.5.7 TB related measurements 

4.5.7.1 Total Number of DL TBs 

a) This measurement provides the total number of TBs transmitted on the downlink in a cell. HARQ 
retransmissions are excluded from this measurement. 

b) CC 

c) On transmission by the eNodeB/RNof TB to UE during the period of measurement, (see 36.321 [16]) 

d) A single integer value. 

e) TB.TotNbrDl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.7.2 Error Number of DL TBs 

a) This measurement provides the number of faulty TBs transmitted on the downlink in a cell. HARQ 
retransmissions are excluded from this measurement. 

b) CC 

c) On receipt by the eNodeB/RN of a NACK from UE which indicates a faulty receiption of TB by UE during the 
period of measurement, (see 36.321 [16]) 

d) A single integer value. 

e) TB.ErrNbrDl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.7.3 Total Number of UL TBs 

a) This measurement provides the total number of TBs on the uplink in a cell. HARQ retransmissions are excluded 
from this measurement. 

b) CC 

c) On receipt by the eNodeB/RN of TB from UE during the period of measurement, (see 36.321 [16]) 

d) A single integer value. 

e) TB.TotNbrUl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 
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4.5.7.4 Error Number of UL TBs 

a) This measurement provides the number of faulty TBs on the uphnk in a cell. HARQ retransmissions are 
excluded from this measurement. 

b) CC 

c) On receipt by the eNodeB/RN of a TB on which CRC fails from UE during the period of measurement, (see 
36.321 [16]) 

d) A single integer value. 

e) TB.ErrNbrUl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.8 Power utilization measurements 

4.5.8.1 Maximum carrier transmit power 

a) This measurement provides the maximum carrier transmit power in the measurement granularity interval. 

b) SI 

c) This measurement is obtained by retaining the maximum value of the total carrier power transmitted in the cell 
within the measurement granularity period. The power includes all radio power transmitted, included common 
channels, traffic channels, control channels. The value is expressed in dBm. 

d) Float in dBm. 

e) CARR.MaxTxPwr 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.5.8.2 Mean carrier transmit power 

a) This measurement provides the mean carrier transmit power in the measurement granularity interval. 

b) SI 

c) This measurement is obtained by computing the mean value of the total carrier power transmitted in the cell 
within the measurement granularity period. The power includes all radio power transmitted, included common 
channels, traffic channels, control channels. The value is expressed in dBm. 

d) Float in dBm. 

e) CARR.AvgTxPwr 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 
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4.5.9 PRB Full utilisation 

4.5.9.1 DL PRB full utilisation 

a) This measurement provides the percentage of time during which all available PRBs for traffic on the downlink 
have been assigned. 

b) SI 

c) This measurement represents the percentage of time during the measurement granularity interval during which 
all available PRBs for downlink traffic have been assigned to UEs. 

d) A single integer value from to 100. 

e) RRU.PrbCongestionDl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.5.9.2 UL PRB full utilisation 

a) This measurement provides the percentage of time during which all available PRBs for traffic on the uplink have 
been assigned. 

b) SI 

c) This measurement represents the percentage of time during the measurement granularity interval during which 
all available PRBs for uplink traffic have been assigned to UEs. 

d) A single integer value from to 100. 

e) RRU.PrbCongestionUl 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.6 UE-associated logical S1 -connection related measurements 
4.6.1 UE-associated logical S1 -connection establishment 

4.6.1 .1 Attempted UE-associated logical 81 -connection establishment from eNB to 

MME 

a) This measurement provides the number of attempted UE-associated logical S 1 -connection establishments from 
eNB to MME. 

b) CC 

c) Transmission of an INITIAL UE MESSAGE by the eNodeB to the MME (See 36.413 [9]). 

d) A single integer value. 

e) SlSIG.ConnEstabAtt 
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f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the AccessibiUty KPI 'E-RAB AccessibiHty' defined in [13]. 

4.6.1 .2 Succesful UE-associated logical S1 -connection establishment from eNB to 

MME 

a) This measurement provides the number of successful UE-associated logical S 1 -connection establishments from 
eNB to MME. 

b) CC 

c) On receipt by the eNB of first message from MME which succeeds INITIAL UE MESSAGE message on an UE- 
associated logical S 1 -connection (See 36.413 [9]). 

d) A single integer value. 

e) SlSIG.ConnEstabSucc 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

i) This measurement is to support the Accessibility KPI 'E-RAB Accessibility' defined in [13] 

4.7 Paging related measurements 

4.7.1 Paging Performance 

4.7.1 .1 Number of paging records discarded at the eNodeB/RN 

a) This measurement provides the number of paging records that are discarded at the eNB/RN for paging occasions 
in each cell. 

b) CC 

c) Reception of a SI AP PAGING message from MME/DeNB, see TS 36.41 3 [9], with UE identity which satisfies 
the following formulae from TS 36.304 [14]. 

X = (T div N)*(UE_ID mod N) 

Y = floor(UE_ID/N) mod Ns 

AND the maximum number of paging records that can be queued for each paging occasion has been reached. 

d) A single integer value. 

e) PAG. DiscardedNbr 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic, 
h) EPS 
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4.7.1 .2 Number of paging records received by the eNodeB/RN 

a) This measurement provides the number of paging records that are received by the eNB/RN for paging occasions 
in each cell. 

b) CC 

c) Reception of a S 1 AP PAGING message from MME/DeNB, see TS 36.413[9]. 

d) A single integer value. 

e) PAG.ReceivedNbr 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic, 
h) EPS 

4.8 Measurements related to equipment resources 

4.8.1 eNodeB/RN processor usage 

4.8.1 .1 Mean processor usage 

a) This measurement provides the mean usage of each key processor during the granularity period. Each equipment 
may have more than one key processor, how to indentify key processor is vendor specific. 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval the usage of the processor and then taking 
the arithmetic mean for each key processor. 

d) Each measurement is an integer value (Unit: %). 

e) EQPT.MeanProcessorUsage.Proceiior/D 

where ProcessorlD identifies the key processor of this equipment, the format ofProcessorlD is vendor specific. 

f) ManagedElement. 

g) Valid for packet switched traffic, 
h) EPS. 

4.8.1 .2 Peak processor usage 

a) This measurement provides the peak usage of each key processor during the granularity period. Each equipment 
may have more than one key processor, how to indentify key processor is vendor specific. 

b) SI. 

c) This measurement is obtained by sampling at a pre-defined interval the usage of the processor and then taking 
the maximum for each key processor. 

d) Each measurement is an integer value (Unit: %). 

e) EQPT.PeakProcessorUsage.Proceiior/Z) 

where ProcessorlD identifies the key processor of this equipment, the format of ProcessorlD is vendor specific. 

f) ManagedElement. 

g) Valid for packet switched traffic. 
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h) EPS. 

4.9 Common LAs of overlapping RAT"s coverage 
4.9.1 Number of incoming IRAT mobility events per LA 

a) This measurement provides the number of incoming IRAT mobility events per E-UTRAN cell. This 
measurement is split into subcounters per LA. 

b) CC. 

c) On receipt by the eNB from UE of an RRCConnectionSetupComplete message in which the most significant bit 
of the 'mmegi' in 'RegisteredMME' IE is '0' (see TS 36.331 [8]). Each RRCConnectionSetupComplete message 
received is added to the relevant per LAI measurement. This definition is only applicable to the EUTRAN cells 
of which the adjacent (including overlaid) RAT is set the most significant bit of the <LAC> with zero. 

d) Each measurement is an integer value. 

e) RRC.IratIncMobility.LA/ 

where LA/ identifies the LAI of the RAT"s coverage the UE comes from. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switched traffic 
h) EPS 

4.10 RF Measurements 
4.10.1 CQI Distribution 

4.1 0.1 .1 Wideband CQI distribution 

a) This measurement provides the distribution of the Wideband CQI (Channel Quality Indicator) reported by UEs 
in the cell. 

b) CC. 

c) This measurement is obtained by incrementing the appropriate measurement bin when a wideband CQI value is 
reported by a UE in the cell. When spatial multiplexing is used, CQI for both code words should be considered. 

d) A single integer value. 

e) CARR.WBCQIDist.BinX 

where X represents the CQI value (0 to 15). 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 

4.1 0.1 .2 Average sub-band CQI 

a) This measurement provides the average value of the sub-band CQI (Channel Quality Indicator) reported by UEs 
in the cell. 
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A subband is a set of k contiguous PRBs where k is a function of system bandwidth. Note the last subband in 
set S may have fewer than k contiguous PRBs depending on ** . The number of subbands for system 

lyOL J^ _ \Nn / Jfcl 

bandwidth given by ^ is defined by I *" I -pj^g subbands shall be indexed in the order of 

increasing frequency and non-increasing sizes starting at the lowest frequency. 

b) CC 

c) This measurement is obtained by computing the average value of the sub-band CQI reported by UEs in the cell 
within the measurement granularity period. One value is produced for each sub-band. The number of sub-bands 
depends on the bandwidth used, as specified in [18]. When spatial multiplexing is used, CQI for both code words 
should be considered. 

d) Float value. 

e) CARR.AvgSubCQI.SubbandX 

where SubbandX represents the sub-band index, as specified in [18]. 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 



4.10.2 Timing Advance Distribution 



a) This measurement provides the distribution of the Timing Advance (Ta) values transmitted by the eNB to UEs in 
the cell. 

b) CC. 

c) This measurement is obtained by incrementing the appropriate measurement bin when a Timing Advance 
Command is sent to a UE in the cell. For Timing Advance Commend see [16] clause 6.1.3.5. 

d) A single integer value. 

e) CARR. TADist.BinX 

where X represents the T^ value (0 to 63). 

f) EUtranCellFDD 
EUtranCellTDD 

g) Valid for packet switching, 
h) EPS 
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5 Measurements related to Relay Node 

5.1 DeNB Reconfiguration related measurements 
5.1.1 RN Reconfiguration 

5.1 .1 .1 Number of RNReconfiguration attempts 

a) This measurement provides the number of RNReconfiguration attempts sent by DeNB. 

b) CC 

c) On transmission by the DeNB of a RNReconfiguration message to RN. Each RNReconfiguration message 
received is added to the relevant measurement. The message is included in 3GPP TS 36.331 [8]. 

d) Each measurement is an integer value. 

e) The measurement name has the form RRC.RNReconAttNbr. 

f) DeNBCapabiUty 

g) Valid for packet switched traffic 
h) EPS 

5.1 .1 .2 Number of RNReconfiguration Completed 

a) This measurement provides the number of RNReconfiguration completed received by DeNB 

b) CC 

c) On receipt by the DeNB of a RNReconfigurationComplete message from RN. Each 
RNReconfigurationComplete message received is added to the relevant measurement. The message is included 
in 3GPPTS 36.331 [8]. 

d) Each measurement is an integer value. 

e) The measurement name has the form RRC.RNReconCmptNbr 

f) DeNBCapabiUty 

g) Valid for packet switched traffic 
h) EPS 
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Annex A (informative): 

Use cases for performance measurements defintion 

This annex provides the concrete use cases for the E-UTRAN performance measurements defined in clause 4. 
Without particular constraint, the following use cases defined for eNodeB apply to following scenarios 

1) eNodeB serving one or moer Relay Nodes 

2) eNodeB without serving any Relay Node 

If the specific constraint is present, which one of the above scenarios the subject use case applies to, is following the 
constraint. 

A.1 IVIonitor of call(/session) setup performance 

Call(/session) setup is one of most important step to start delivering services by the networks to users. 

The success or failure of a call(/session) setup directly impacts the quality level for delivering the service by the 
networks, and also the feeling of the end user. So the success or failure of call(/session) setup needs be monitored, this 
can be achieved by the calculation of call setup success rate which gives a direct view to evaluate the call setup 
performance, and the analysis of the specific reason causing the failure to find out the problem and ascertain the 
solutions. 

In addition, the time duration of the call(/session) setup need to be monitored as it impacts the end user experience, and 
by comparison with operator"s benchmark requirements, the optimization may be required according the performance. 

And due to different priority and tolerance for different service type with different OoS level in the networks, the 
monitor needs to be opened on each service type and OoS level. 

To complete the call(/session) setup procedure, E-UTRAN is mainly responsible for the establishment of radio and S 1 
signaling connection and service bearer by the RRC connection establishment (See 3GPP TS 36.331 [8]), RRC 
connection reestablishment after RRC connection dropped due to some reasons like radio link failure or handover 
failure etc (See 3GPP TS 36.331[8]) E-RAB setup (See 3GPP TS 36.413[9]) and Initial UE Context Setup (See 3GPP 
TS36.413[9]) procedure. 

To support the monitor of success or failure of the call(/session) setup, the performance measurements related to RRC 
connection estabhshment (See 3GPP TS 36.331 [8]), RRC connection reestabhshment (See 3GPP TS 36.331 [8]) 
procedure, and the performance measurements related to E-RAB setup (See 3GPP TS 36.41 3 [9]) and Initial UE Context 
Setup (See 3GPP TS 36.413[9]) procedure for each QoS level are required To support the monitor of time duration of 
setup call(/session) setup, the performance measurements related to RRC connection setup time and E-RAB setup time 
are required. 



A.2 IVIonitor of E-RAB release 



E-RAB is the key and limited resource for E-UTRAN to deliver services. The release of the E-RAB needs to be 
monitored as: 

- an abnormal release of the E-RAB will cause the call(/session) drop, which directly impacts the QoS delivered by the 
networks, and the satisfaction degree of the end user; 

- a successfully released E-RAB can be used to setup other requested calls(/sessions). The E-RAB failed to be released 
will still occupy the limited resource and hence it can not be used to admit other requested calls(/sessions). 

From a retainability measurement aspect, E-RABs do not need to be released because they are inactive, they can be kept 
to give fast access when new data arrives. 
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To define (fi-om an E-RAB release measurement point of view) if an E-RAB is considered active or not, the E-RABs 
can be divided into two groups: 

a. Continuous flow, E-RABs that are always considered active, i.e. independent of if there is ongoing 
traffic or not at the moment. Examples: VoIP sessions. Real-time sessions. Live streaming sessions. 

b. Bursty flow, E-RABs that are only considered active when there is data in UL/DL buffer. 
Example: Web sessions. 

How to decide for a particular QCI if the E-RAB is of type bursty flow or continuous flow is outside the scope of this 
document. 

The specific reason causing the abnormal and failed release of the E-RAB is required in order to find out the problem 
and ascertain the solutions. And due to different priority and tolerance for different service type with different OoS level 
in the networks, the monitor needs to be opened on each service type with OoS level. 

The E-RAB can be released by E-RAB Release procedure (See 3GPP TS 36.413[9]) , UE Context Release procedure 
(See 3GPP TS 36.413[9] and 3GPP TS 36.423[10]) procedure. Reset procedure(See 3GPP TS 36.413[9]) either 
initiated by eNodeB or MM, Path Switch procedure (See 3GPP TS 36.41 3 [9]) and Intra-eNB HO procedure (See 3GPP 
TS 36.331 [8])E. 

So performance measurements related to E-RAB Release (See 3GPP TS 36.413[9]) and UE Context Release (See 3GPP 
TS 36.413[9]) procedure for each service type with QoS level are necessary to support the monitor of E-RAB release. 



A.3 Monitor of E-RAB level QoS modification 

When an E-RAB has been established, the QoS it experiences in the E-UTRAN is dependent upon the E-RAB level 
QoS parameters established for the bearer, together with settings of other bearers established in the same cell. If the 
QoS experienced by a bearer does not meet the expected performance, or the resource need be reassigned for other 
bearers, the E-RAB level QoS may be adjusted (typically with a knock-on effect onto other bearers). 

So the modification of E-RAB level QoS parameters needs to be monitored, and due to different priority and tolerance 
for different service type with different OoS level in the networks, the monitor needs to be opened on each target 
service type with OoS level. 

The E-RAB level QoS can be modified by E-RAB Modify procedure (see 3GPP TS 36.41 3 [9]), in which the MME 
entity instructs the eNodeB to change one or more QoS parameters on an E-RAB using the E-RAB MODIFY 
REQUEST message. The eNodeB typically makes the adjustments as instructed (and adjusts the RRM applied to the 
bearer appropriately) but in some circumstances the bearer modification can fail. The eNodeB returns an E-RAB 
MODIFY RESPONSE message that tells the MME whether the modification was successful or not - for an 
unsuccessful modification a cause value is included. It is important for OAM to measure the failure rate of the bearer 
modifications, this information can be used, for example, to make adjustments to OAM CM settings. 



A.4 Overview handover related Use Cases 



Use Case 

1 


PM KPI / elementary object 
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Continuous Network Supervision: Supervision of overall 
handover performance. It is essential in network operations to 
follow the success rate of various handover. Low handover 
success rate will impact user experience, therefore it is 
important to define measurements to follow handover success 
rate. 



- outgoing Intra RAT HO Success Rate (cell) *1 

- outgoing Inter RAT HO Success Rate (cell) *1 

- outgoing Inter System HO Success Rate (cell) *1 *3 

- outgoing Intra Frequency HO Success Rate (cell) *1 

- outgoing Inter Frequency HO Success Rate (cell) *1 

- outgoing Intra eNB/RN HO Success Rate (cell) *2 *2.1 

- outgoing Inter eNB HO Success Rate (cell) *2 *2.2 

- outgoing HO to the cells outside the RN 

*1 : It is expected that the HO success rate may vary depending 
on the respective scenarios : intra-RAT, inter-RAT, inter System, 
intra frequency, inter frequency 



*2: it is expected that the HO success rate may vary depending 

on the used external interfaces 

*2.1 : For the Intra-DeNB handover, the handover from a DeNB cell to 
an RN under the same DeNB shall be counted separately as the 
handover happens between E-UTRAN and RN. 

*2.2: For the handover from the DeNB to another eNB/DeNB, the 
forwarded handovers for RN in the source DeNB shall not be counted 
as these handovers are controlled by RN so cannot directly reflect 
DeNB handover performance. 



*3: inter system : LTE- non 3GPP HO 



Continuous Network Supervision: Supervision of the signal 
strength when handovers are triggered. This information is 
useful for evaluating the customer experience (e.g. 
throughput) at the cell edge and during handover as well for 
network planning purposes (e,g, signal strength at the cell 
edge). 

Troubleshooting: detect a "bad" configuration/neighbor in a 
particular direction by analyzing abnormal measurement 
report causing HO. 



Signal strength of the serving and neighbouring cell reported by the 
UE in handover triggering measurement reports in EUtranRelation.. 



Troubleshooting: Detection of bad handover relation. The first 
use case provides the overall performance of handover 
success rate on E-UTRAN cell level, but it is essential to get a 
knowledge between which cell pairs the handover success 
rate is low. Therefore it is important to know the success rate 
on neighbor cell relation basis. 



HO Success Rate (neighbourcell) 



Troubleshooting: Reason for started handover 

To go for further analysis of handover failures, it is essential to 
know what causes the handovers. For this we need to know 
the success rate of handovers per HO reason. 



outgoing HO Success Rate per HO reason i 
neighbor cell) *4 



*4 different results expected e.g. emergency or normal HO 



Troubleshooting: Reason for failed handover. To go for further 
detailed analysis for handover failure it is important to know 
what the reason for handover failure was, or whether the 
handover was assisted by measurement gaps or was with 
DRX. 



■ outgoing HO Failure Distribution Rate (cell+neighbourcell) 

■ HO Path Switching Failure Distribution Rate (cell or Interface) 

■ HO Failure Rate DRX/ Non DRX (cell) *5 

■ Inter frequency HO Failure Rate Meas gap assisted / not assisted 
(cell) *5 
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It is also important to know if measurement gaps and DRX are 
helping in handover procedure or not. (i.e. what is the 
handover failure rate if measurement gaps are switched on. 
Measurement gaps and DRX can cause more load and 
battery consumption to the UE, therefore if these are not 
causing any changes in handover failure rate, operators may 
not use them) 


*5: measurement only on cell basis and not per neighbourcell 
due to amount of counters as mentioned above. 


Network Planning: Traffic flow analysis 
or 

Network Planning: Handover traffic optimization 


- outgoing Intra RAT HO Success Rate (neighbour cell) 

- outgoing Inter RAT HO Success Rate (cell) 

- outgoing Inter System HO Success Rate (cell) 



A. 5 Monitor of cell level QoS and radio resource 
utilisation 

In an E-UTRAN cell the quality of service achieved is directly influenced by a number of factors, including: 

• Loading of users on the cell 

• Traffic loading and characteristics 

• UE locations and mobility 

• RRM policies 

o Scheduling 

o congestion control 

o admission control 

o layer 2 protocol configuration 

• Mapping of traffic to QCI 

• Setting of QoS parameters other than the QCI. 

It is very important to be able to monitor the QoS to determine whether the combined effect of these policies, 
algorithms and external factors is satisfactory. Unsatisfactory QoS may be rectified by adjusting policies and RRM 
settings, for instance. 

Cell bit-rate 

A fundamental measure of QoS is the throughput (data rate) of the cell. The total cell throughput measured across all 
radio bearers gives an indication of the loading and activity in the cell. Adding a per QCI counter allows the loading on 
the different QCIs to be measured. For example, if QCI 1 is used exclusively for VoIP then the loading of 
conversational speech can be directly determined. Finally, the maximum throughput can indicate to the operator 
whether there is enough capacity in the network; for example, is the backhaul sufficient. Separate counters should be 
configured on the downlink and uplink. Complexity may be reduced by performing the counters at layer 3, giving the 
ingress bit-rate to the eNB on the downlink and the egress bit-rate from the eNB on the uplink. 

Cell throughput includes both User Plane data and Control Plane data. To support the User Plane data, necessary 
Control Plane data also need to be transmitted. This Control Plane data although required, will not be perceived (felt) by 
the User. The total cell throughput helps to evaluate the usage of bandwidth and radio resource. 

Operators ideally want to see the Control Plane data as small as possible when compared to the User Plane data without 
compromising on the service. 
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Hence it is important to monitor the total cell throughput as well as how much is occupied by Control Plane Data. 

Number of actives UEs 

It is also of interest to determine how many users are enjoying the throughput numbers determined for each QCI. 
Therefore, we may count the number of users that are active for each QCI - here active users have data queued pending 
transmission. A simple division of the throughput (data rate) of a QCI by the number of active users on the QCI 
indicates the throughput per user on the QCI. For example, taking QCI 1 this metric could indicate the typical codec 
rate being employed in the cell. Alternatively, for QCI 9 supporting low priority TCP-based traffic it can indicate the 
typical bandwidth pipe size for a user when he has data to send / receive. 

DL packet delay 

Latency is of prime concern for some services, particularly conversational services like speech and instant messaging. 
A counter is added to measure the mean delay for IP packets incurred within the eNodeB. Separate counters are 
provided per QCI which are particularly useful when the QCI is used by very few services and the packet sizes vary 
little. It is only practical to measure packet delays on the downlink. 

In case of the eNodeB serving one or more RN, the packet delay includes both the internal processing delay at eNB) 
and UE/RN as well as the packet transferring delay on the radio link. As RN UE"s packets need to be transferred via 
between E-UTRAN snfRN while packets for UEs directly connected to eNB need to pass through only Uu interface, 
packet delay optimization mechanism may be different for RN UEs and eNB UEs. Therefore it is beneficial to have 
measurements on packet delay separately for packets transmitted between the eNodeB and UEs and for packets 
transmitted between the E-UTRAN and RNs. 

DL packet drop rate 

When a cell is heavily loaded congestion can take place. When congestion is not severe, the impact is typically the 
incurrence of additional delay for non-GBR radio bearers. However, when congestion is severe the eNodeB may be 
forced to discard packets. It is important for the operator to have visibility of packet discard so that corrective action 
can be instigated (for example, by adjusting admission control settings in the network). It is only practical to measure 
packet discards on the downlink. Packet discards on handover should not be included in the count. 

PRB Usage 

The resource utilisation, measured in terms of physical resource blocks (PRBs), is a useful measure of whether a cell is 
lightly loaded or not. Loading is a key input to network capacity planning and load balancing. Furthermore, when 
resource utilisation per QCI is reported the distribution of resources between different services can be estimated. 

For a RN that requires subframe configuration, the RN can only be scheduled by the eNodeB within subframes 
configured for RN, while macro UE can be scheduled in any subframe. Therefore in certain scenario it may be possible 
that the PRB usage is different for the subframe configured for the RN and for any other subframe. For example, in case 
there are many RNs in the network and only a few UEs connected directly to the eNodeB, it may happen that the PRB 
usage in the subframe configured for RN is quite high, while the subframes used for UEs is low. Therefore it is 
beneficial to measure the PRB usage separately for RN and the total PRB usage. The total PRB usage includes the PRB 
usage for RN traffic and UE traffic, while the RN PRB usage includes only PRB usage for RN traffic. 

Resource Full Utilisation 

Resource congestion is a critical situation in the network that needs to be monitored closely in order to be assessed and 
addressed immediately (e.g. by expanding related resources). Measurements reflecting the time during which the 
resources are fully used are needed to properly assess the congestion. Congestion affects PRB so appropriate congestion 
measurements are needed. 

Transport Resource Usage 

Transport resource utilisation provides information on the overall traffic of an eNodeB with the rest of the network, 
together with information on the traffic of the individual cells it gives the ability to localise bottlenecks. On the other 
hand it is a key input for planning of timely expansion of transport (backhaul) resources in the network provides . 
Measurements enabling to track the transport resource utilisation are therefore useful. 

Hardware Resource Usage 
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Hardware resource utilisation provides information on the overall load of an eNodeB, together with the information on 
the individual loads it gives the ability to localise bottlenecks. On the other hand it is a key input for planning of 
timely expansion of hardware resources in the network. Measurements enabling to track the hardware resource 
utilisation are therefore useful. 

Downlink Air interface packet loss rate 

The downlink air interface packet loss can be directly compared with the PELR value of a QCI to see if the packet loss 
(over the air interface) aspect of quality of service is being met within the cell (see [12] for more details on PELR). On 
the downlink this measurement can be added to the congestion losses (see DL packet drop rate) to determine the total 
packet loss rate at the eNodeB. Consequently, the downlink useful bit-rate can be estimated by scaling the 
measurement of the downlink PDCP ingress bit-rate by (1 - DL packet drop rate) (1 - air interface packet loss rate). 

In case or RN deployment the communicstion between the E-UTRAN and RN is going through the air interface. It is 
possible that the radio conditions are bad, which can lead also to high packet loss rate, which can contribute also 
whether the packet loss aspect of the quality of service is met or not. Therefore it is beneficial to have separate packet 
loss rate measurement for RN traffic and for the traffic connected directly to the eNodeB. 

Uplink packet loss rate 

The uplink air interface packet loss rate (per QCI) can be compared directly with the PELR defined for that QCI. An 
estimate of the uplink air interface packet loss may be provided by the 'Uplink PDCP SDU loss rate'. This uplink 
measurement is based on PDCP sequence numbers and cannot precisely measure the air interface losses. Any packets 
discarded by the UE within the protocol stack (i.e. at layer 2) are also counted since they will have been given a PDCP 
sequence number. Discards at layer 3 are not counted. 

In case or RN deployment the communicstion between the E-UTRAN and RN is going through the air interface. It is 
possible that the radio conditions are bad, which can lead also to high packet loss rate, which can contribute also 
whether the packet loss aspect of the quality of service is met or not. Therefore it is beneficial to have separate packet 
loss rate measurement for RN traffic and for the traffic connected directly to the eNodeB. 

RACK Usage 

The RACH plays a vital role in the following procedures: 

Initial access from RRC_IDLE; 

Initial access after radio link failure; 

Handover requiring random access procedure; 

DL data arrival during RRC_CONNECTED requiring random access procedure; 

UL data arrival during RRC_CONNECTED requiring random access procedure; 
Furthermore, the random access procedure takes two distinct forms: 

Contention based using a randomly selected preamble (applicable to all five events); 

Non-contention based using a dedicated preamble (applicable to only handover and DL data arrival). 

In the use-case of RACH configuration optimization, received Random Access Preambles and a contention indicator are 
signalled across an OAM interface. 

Monitoring of the preamble usage in a cell allows the operator to determine if the resources allocated to the RACH by 
the eNodeB are appropriate for the number of random access attempts. If the resources are underutilised then the 
operator may reconfigure the eNodeB (via CM) to allocate less resource to RACH thereby freeing up resource for other 
uplink transmissions. Alternatively, if the resources are heavily utilised then this is indicative of RACH congestion 
leading to increased latency for the procedures listed above. To this effect, measurements directly reflecting RACH 
congestion experienced by the eNodeB and by the UEs are useful. 

The eNodeB can partition the RACH resource between dedicated preambles, randomly selected preambles in group A 
and randomly selected preambles in group B. This partitioning can be evaluated when usage measurements are made 
on each set separately. 



£75/ 



(3GPP TS 32.425 version 1 1 .3.0 Release 11) 66 ETSI TS 1 32 425 V1 1 .3.0 (201 2-1 1 ) 

To further monitor and analyze the latency of the procedures listed above created at the RACH level, the measurement 
of the number of RACH preambles sent per RACH attempt is useful. 

RACH optimisation function optimises RACH related configurations to achieve minimizing of access delays and 
random access collision probability for all the UEs. eNB may request the UEs to report the number of attempts to access 
the network (numberOfPreamblesSent in TS 36.331 [8]). Based on the attempting number of random access of all the 
UEs, the eNB can know the distribution of RACH preambles sent by UEs and calculate the access probability (AP) of a 
cell accurately. The eNB may also request the UEs to report contention detected while attempting to access the network 
(contentionDetected in TS 36.331 [8]). Based on the estimated time per random access and the estimated contention 
level in the network, the eNB can estimate the access delay probability (ADP) of a cell. 



A.6 Monitor of the number of connected users 

The number of the connected users in each cell is valuable information for operators to know how many uses are 
connecting to E-UTRAN per cell basis. This kind of information can help operator to tune the admission control 
parameters for the cell and to do load balancing between cells to ensure that the target percentage or number the of users 
admitted achieve the target QoS. 



A.7 Monitoring of interference situation 

In the LTE radio technology interference has to be coordinated on the basis uplink and downlink i.e. in a coordinated 
usage of the UL resources (Physical Resource Blocks, PRBs) and DL Transmitted Power, which lead to improve SIR 
and corresponding throughput. These are achieved by means of mechanisms employing channel quality indicators in 
support of scheduling/radio resource allocation functions. 

These RRM functions in the eNB require the setting of frequency / power restrictions and preferences for the resource 
usage in the different cells. Setting and updating these parameters is the task of a network optimisation (done by 
operator or automatically by SON). 

Use cases for the related interference measurements are e.g. optimisation of ICIC related RRM functionality, the 
detection of long distance interferer and the interference due to spurious emissions of neighbour cells. The later case is 
assumed only in high load scenarios or unsufficent ICIC functionality due to the the fact that ICIC functionality would 
minimise interference autonomously if sufficient bandwidth is available. 

The necessary measurements to identify and anylse the interference situation as input for optimisation tasks has to be 
defined. 



A.8 Monitor of ARQ and HARQ performance 

Reliable Packet Delivery is one of the important Performance factor for a better User experience. HARQ 
retransmissions at the MAC layer ensure reliable packet delivery 

In addition, RLC can be configured to operate in acknowledged mode for those applications that need very low packet 
drops and can tolerate a slightly higher delay from RLC retransmissions. 

If a MAC PDU is not delivered, HARQ takes care of retransmitting (upto a maximum configurable number). If all the 
retransmissions fail at MAC layer, and if RLC is configured to operate in acknowledged mode, RLC's ARQ 
mechanism will take care of any residual packet errors. 

It is important to 

a) maintain the block error rate or packet error rate within tolerable limits 

b) ensure that HARQ retransmissions take care of most packet errors, instead of relying on RLC layer retransmissions 
(which would increase the delay). 

So, it is important to monitor the performance of these schemes. 

ARQ Performance if viewed at QCI level can help in monitoring the distribution for each of the services. 
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HARQ Performance if viewed at MCS (Modulation Coded Scheme) can help in monitoring the MCS Performance also. 

A.9 Monitoring of RF performance 

RF Performance reflects the cell loading levels and abnormal conditions. 

In the Downlink, Power Resources are managed by the EUTRAN Cell(RAN). 

More Power Resources may help in increasing the Capacity of the System. Hence, there the power resources could be 

effectively used to optimize the Capacity of the System. 

Hence there is a need to keep monitoring the Power Resource Utilization in % and also in absolute terms. 

Monitoring of the quality of RF signal in the cell is useful for the purpose of NW planning and overall service quality 
assessment. Measurements of Channel Quality Indicator (CQI) reported by UEs is a useful metric reflecting RF signal 
quality and service quality. 

Timing advance measurements reflect the distance of the UE from the cell antenna. This information reflects the 
optimality of the cell antenna location with respect to the cell traffic and is useful in the NW planning process. 

Monitoring interference, both uplink and downlink, is an important aspect of monitoring RF performance. For this 
purpose, monitoring of UL interference power is useful. 

Interference signals in a number of different ways, including frequency, frequency band, direction of interfering signals, 
etc. can also be classified by System internal interference and External interference. By efficient frequency planning 
and careful 

Selection of base station locations, the impact of interference signal can be effectively controlled within an acceptable 
scope. uplink interference disturbs the base station receiver. Once the base station receiver is compromised, it leads to 
receiving code errors for the whole base station and the site"s entire service area is degraded including its network and 
service. Of course, customer satisfaction is negatively impacted. So it is very useful to monitor uplink interference of 
communication system to do network optimization. 



A.1 IVIonitor of paging performance 

In EUTRAN, Paging is under the control of the MME. When the MME wants to page a UE it has to page it in all cells 
that belong to the TA(s) to which the UE is registered. 

The paging load per cell is an important measure for the operator as it allows the operator to properly dimension the 
resources for paging in the E-UTRAN Cell . 

At an E-UTRAN Cell it makes sense to measure the number of discarded paging messages if this is due to some 
problem in the eNodeB, such as paging occasion overflow. In that scenario the periodicity of paging occasions can be 
reconfigured in order to ensure that all paging messages are transmitted by the eNodeB in the first available paging 
occasion, thereby avoiding paging delays and extended call setup delay. 

Operators need to know when such an event occurs, in order to identify if the problem is at the E-UTRAN cell level or 
not. 

In addition to discarded paging records measurement, it is important to know total paging records received so that 
discarded paging records ratio can be derived. 

Total number of paging records received is important in the sense that, it may be fine if the discarded paging records are 
high if discarded paging records ratio is small. On the other hand, it may be problematic if discarded paging records are 
low, if discarded paging records ratio turn out to be high. 
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A.1 1 Use case of eNodeB processor usage 

When network is very busy, for example on important holiday or emergency events happened, the traffic of one 
eNodeB is very heavy. So eNodeB processor usage measurements are very important to indicate eNodeB processor load 
capability. If eNodeB processor usage is too high, operator must take action to avoid network paralysis. 



A. 12 Monitor of simultaneous E-RABs 

E-RAB is one of the EUTRAN Cell resources which are limited in number. 

Hence along with the E-RAB Setup Success Rate, there is a need to keep monitoring the simultaneous E-RABs and 
having them at QCI level can help in learning the service distribution in time periods. 

Average / Maximum simultaneous E-RABs, can help to know the average / maximum utilization of the resources in 
time periods, thereby helping to do necessary resource capacity engineering. 



A. 13 IVIonitoring of IVIobility Robustness Optimization 
(MRO) 

The following measurement is defined specifically to monitor the performance of handover optimisation: 

Number of handover failures for MRO. 

The measurement examines 'handover related events' in which the serving cell of a RRC connected UE is changed. 
Handover related events are either normal successful handovers, or they are failures. Different failure modes are 
possible and the measurement provides counts for the occurrences of the failure modes related with MRO, 'too early', 
'too late' and 'to wrong cell'. The detailed definitions of these modes are captured in [12]. The counters provide visibility 
of the mix of failure problems that the handover optimistion function is tackling. 

In addition to event-based (i.e. reactive) optimization of handover performance, a pro-active optimization is possible by 
monitoring the dynamics of handover triggering from UE measurement reports. 

A. 14 IVIonitor of BLER performance 

The TB Error Rate in UL/DL can directly reflect the BLER, and has an influence on MCS selection and user 
throughput. It can be helpful to estimate the performance of radio resource management like radio resource schedulein 
transport layer and be helpful in trouble shooting. Furthermore, they should be taken into account to optimize the 
system performance. To obtain TB Error Rate by calculating, the number of total and error TBs transmitted in a cell 
should be monitored. 

A.I 5 IVIonitoring of common LAs of overlapping target 
RAT"s coverage 

For CS fallback in EPS, as defined in section 5. 1 A of 3GPP TS 23.272 [17], the fallback procedure is likely to be faster 
if the network can allocate a Location Area to the UE that is the LA of the overlapping target RAT's coverage. For this 
situation, the MME should avoid allocating TAI lists that span multiple Location Areas of the target RAT, this can be 
achieved by: 

configuring the E-UTRAN cell's TAI to align the LA boundary of the target RAT; 

the MME being configured to know which TAIs are within which LA; and 

- the MME using the TAI of the current E-UTRAN cell to derive the LAI. 
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Also as specified in section 4.3.4 of 3GPP TS 23.272 [17], to facilitate the alignment of TA boundaries with LA 
boundaries, the E-UTRAN can gather statistics (from the inbound inter-RAT mobility events of all UEs) of the most 
common LAs indicated in the RRC signalling. 

From such measurements per E-UTRAN cell basis, operators 1) can know the common LA(s) of the overlapping target 
RAT"s coverage for each TA, which is useful to configure the TAI list within which LA boundary to MME, operators 
can also 2) detect the case that TA spans multiple LAs if different most common LA(s) is/are reported from the E- 
UTRAN cells in the same TA, operators may take actions to rectify it if needed. 



A. 16 Monitoring of Energy Saving 



Beside monitoring of the energy consumption it is also important to differentiate if the cell unavailability or the failure 
of the RRC connection establishment happens because of Energy Saving as Energy Saving Management feature is by 
the Operator on purpose. Therefore such failures should be distinguishable from other network failures, therefore should 
be counted separately. With the separate cell unavailability counter due to Energy Saving makes it possible to deduct 
the cell downtime due to Energy Savings from the total cell outage. 



A.17 IVIonitoring of RNReconfiguration 

The purpose of RNReconfiguration related procedure is to configure/reconfigure the RN subframe configuration and/or 
to update the system information relevant for the RN in RRC_CONNECTED. 

The system information and subframe configuration is very important for RN, but the RN does not need to apply the 
system information acquisition and change monitoring procedures, if configured with an RN subframe configuration. 
Upon change of any system information relevant to an RN, E-UTRAN provides the system information blocks 
containing the relevant system information to RNs with an RN subframe configuration via dedicated signalling using 
the RNReconfiguration message. This dedicated signalling replaces any stored system information acquired through the 
system information acquisition procedure. 

Because the RN is semi-duplex, to avoid the transmission conflict between access link (between UE and RN) and 
backhaul link (between RN and DeNB), the subframe of RN is semi-statically assigned (see TR 36.814) and the 
configuration information is included in the RNReconfiguration message. 

During the RN operation, failures of backhaul link will cause unsuccessful RN reconfiguration. In that case, RN will not 
get any response from DeNB. The defined performance counter will help to compute how many respose messages are 
missing. Depending on this result, operators could easily make network planning to consider fix or optimize the 
backhaul link quality. 



A. 18 IVIonitoring of E-RAB setup for incoming HOs 

The E-RAB needs to be established in the target cell during HO, the success or failure of E-RAB establishment in the 
target cell during HO results in if the services beared on the E-RABs can continue or not after HO, thus whether or not 
the E-RAB can be successfully established for incoming HO impacts the user experience. 

The unsuccessful setup of E-RABs with different QCIs could lead to different user experience, thus the E-RAB setup 
for incoming HOs needs to be monitored per QCI. 
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